MVT change in new opcode numbers?

[Karen Kinnear]

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 <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
> 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
>  
>