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. thanks, Karen > On Jul 27, 2017, at 2:09 PM, Bjorn B Vardal <[email protected]> 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 <[email protected]> > Sent by: "valhalla-spec-experts" > <[email protected]> > To: [email protected] > Cc: > 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) > > thanks, > Karen > >
