Value Type on stack in the interpreter
john.r.rose at oracle.com
Sat Apr 1 00:00:19 UTC 2017
On Mar 31, 2017, at 4:30 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> À: "Rémi Forax" <forax at univ-mlv.fr>
>> Cc: valhalla-spec-experts at openjdk.java.net
>> Envoyé: Samedi 1 Avril 2017 01:06:07
>> Objet: Re: Value Type on stack in the interpreter
>> On Mar 31, 2017, at 8:57 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> I've some trouble to see how value types are laid on stack (conceptually, not
>>> necessary the real implementation).
>>> First, i may be wrong but it seems that vload do not reference the corresponding
>>> Q-type, so i wonder how the verifier knows that it can then access to component
>>> of the value type.
>>> Then, it seems that value type use one slot on stack, so the components (and the
>>> boxed reference if it exists) has to be stored somewhere but there is no
>>> corresponding max value type buffer size.
>> In the interpreter value types all share a common _carrier type_ which includes
>> metadata about the size and type of the value being stored, plus a pointer to
>> the actual storage. The actual storage may be on the heap, or maybe not.
>> We are prototyping with thread-local arenas for the non-heap case.
>> There are also ways to store value payloads in the stack frame, but
>> in that case there is a special handshake when you want to return a
>> value from a method call.
> why the type of the value is stored in the _carrier_type_ and not in the vload/vstore instruction.
There are two choices: 1. store the type metadata in the carrier (on stack and in local),
or 2. reaffirm the type metadata at every use site (not just vload/vstore). #1 allows
simpler bytecodes which put less load on the verifier. A significant subset of #2
is needed, anyway, for telling the GC where to find object references. So #2 wins.
>> From the verifier's point of view, there isn't much difference between
>> the various Q-types. We will probably track classes of Q-types, mainly
>> to simplify vgetfield operations.
> pre-compute the offset of a component ?
Yes, as with objects. The techniques are basically the same.
Q-types behave like on-stack objects. (They are also copy-able
hence identity-free, and they are also non-nullable.)
More information about the valhalla-spec-observers