Value Types Bytecodes - "Level 0" prototype

Brian Goetz brian.goetz at
Tue Jun 28 16:31:31 UTC 2016

First, the usual disclaimer: this is a total "throw something against 
the wall" prototype, everything *will* change.

The existing bytecode set makes strong distinction between primitives 
and refs; the key safety promise of the verifier is that we will never 
let you cast an object ref to an int.  So refs are moved with 
aload/astore, and ints with iload/istore.  The reason there are separate 
bytecodes for I vs J (but not I vs B,C,S -- here, the VM mostly erases 
byte/short/char to int) is that I and J have different size.  So it is 
with values; flattened values have varying sizes too.  So the v* 
bytecodes being prototyped here are the value equivalent of 
iload/istore/etc, but with an extra operand so you know *what* value 
type (QPoint vs QComplex) is being moved.

Logically, these work only on the flat representation -- a Q type, not 
an L-type.  But the VM is free to transparently box a value if it wants 
to -- as long as this conversion is invisible to the bytecode consumer.  
So if the *user* wants to convert a flat Point into its box equivalent, 
it will explicitly box, somehow (current thinking is an `a2b` bytecode, 
which names a source type and a target type, which will convert from 
QPoint to LPoint.)

On 6/28/2016 11:27 AM, Paul Benedict wrote:
> Do the value byte codes work only on the "flat" representation of the type?
> I don't think Valhalla has gotten to the point of boxing the type (has
> it?), but I am curious if these also operate on the boxed representation?
> Cheers,
> Paul
> On Tue, Jun 28, 2016 at 6:57 AM, David Simms <david.simms at> wrote:
>> Recently pushed some basic "value type" prototype code to Valhalla
>> repository.
>> Usual caveats apply *this is a prototype*, things will change, the format
>> of the bytecodes or whether we go ahead with said bytecodes at all. From
>> bytecodes.hpp (mostly correspond to aref bytecodes):
>>      // value-type bytecodes
>>      _vload                = 203, // 0xcb
>>      _vstore               = 204, // 0xcc
>>      _vaload               = 205, // 0xcd
>>      _vastore              = 206, // 0xce
>>      _vnew                 = 207, // 0xcf
>>      _vnewarray            = 208, // 0xd0
>>      _multivnewarray       = 209, // 0xd1
>>      _vreturn              = 210, // 0xd2
>>      _vgetfield            = 211, // 0xd3
>>      _typed                = 212, // 0xd4
>>      _invokedirect         = 213, // 0xd5
>> "Level 0" Prototype: Currently value types are simply modelled with oops
>> and heap allocated for simplicity (class derives from instanceKlass). The
>> semantics of value types are mostly there, but there is currently no stack
>> or thread local allocation, work for the future. There is initial support
>> for flattened compositions of values and array elements.
>> The prototype "value types" have no JIT or verifier support, so code that
>> wants to play with value types:
>>   * x86_64, Linux and Mac only.
>>   * "-noverify -Xint", no verify or JIT support
>>   * GC should be fine, not that we have extensively tested all GC
>>     configurations
>>   * invokedirect can execute values methods, that's about it
>>       o the type system isn't anywhere near being completely defined
>>         (e.g. should value types implement interfaces, and if so, how)
>> Folks that don't use value types shouldn't notice any restrictions using
>> the JIT etc.
>> Cheers
>> /David Simms

More information about the valhalla-dev mailing list