On Mar 31, 2017, at 4:30 PM, fo...@univ-mlv.fr wrote: > > ----- 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.
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
