Value Types Bytecodes - "Level 0" prototype
Brian Goetz
brian.goetz at oracle.com
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 oracle.com> 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