----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Rémi Forax" <[email protected]> > Cc: [email protected] > 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 <[email protected]> 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
