MVT change in new opcode numbers?
karen.kinnear at oracle.com
Thu Jul 27 19:10:31 UTC 2017
Sigh - it does matter to us where it starts - we do quickening internally using the higher ranges and our code knows about
ranges for “real” java byte codes vs internal byte codes.
If it is possible we would appreciate the lower numbers since the higher numbers would slow down our range checking.
> On Jul 27, 2017, at 2:09 PM, Bjorn B Vardal <bjornvar at ca.ibm.com> wrote:
> If you want to make it contiguous, does it matter to you (HotSpot) where it starts? If not, the most practical for us would be 217-225. If that doesn't work, I believe we'll be able to work with 203-211.
> ----- Original message -----
> From: Karen Kinnear <karen.kinnear at oracle.com>
> Sent by: "valhalla-spec-experts" <valhalla-spec-experts-bounces at openjdk.java.net>
> To: valhalla-spec-experts at openjdk.java.net
> Subject: MVT change in new opcode numbers?
> Date: Thu, Jul 27, 2017 1:38 PM
> Dan Smith, Bjorn, Dan H, Remi -
> Does it work for you if we change the JVMS to use the following value-type byte codes - i.e.
> make them contiguous?
> In the hotspot implementation, we ran out of internally-usable byte codes when we left holes here.
> _vload = 203, // 0xcb
> 248 _vstore = 204, // 0xcc
> 249 _vaload = 205, // 0xcd
> 250 _vastore = 206, // 0xce
> 251 _vreturn = 207, // 0xcf
> 252 _vdefault = 208, // 0xd0
> 253 _vwithfield = 209, // 0xd1
> 254 _vbox = 210, // 0xd2
> 255 _vunbox = 211, // 0xd3
> (note: we removed vgetfield)
More information about the valhalla-spec-observers