Value Type on stack in the interpreter

[forax at univ-mlv.fr]

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

Ok,
why the type of the value is stored in the _carrier_type_ and not in the vload/vstore instruction.

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

> 
> — John

Rémi