Value Type on stack in the interpreter

[John Rose]

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.
> 
> Ok,
> 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.)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170331/eeff1e8f/attachment-0001.html>