Yes, we should be able to work with the lower range.
----- Original message -----
From: Karen Kinnear <[email protected]>
To: Bjorn B Vardal <[email protected]>
Cc: [email protected]
Subject: Re: MVT change in new opcode numbers?
Date: Thu, Jul 27, 2017 3:10 PM
Sigh - it does matter to us where it starts - we do quickening internally using the higher ranges and our code knows aboutranges 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,KarenOn 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
