----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Rémi Forax" <fo...@univ-mlv.fr> > Cc: valhalla-spec-experts@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 <fo...@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
