> On Nov 22, 2017, at 9:42 AM, fo...@univ-mlv.fr wrote: > > > > ----- Mail original ----- >> De: "daniel smith" <daniel.sm...@oracle.com> >> À: "Remi Forax" <fo...@univ-mlv.fr> >> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> >> Envoyé: Mercredi 22 Novembre 2017 16:32:36 >> Objet: Re: Design notes for next values iteration > >>> On Nov 22, 2017, at 2:42 AM, Remi Forax <fo...@univ-mlv.fr> wrote: >>> >>> I think we do not need Q types, Q types are use site annotations, and here >>> we >>> want declaration site annotations (let say that this class is a value class, >>> the ACC_VALUE). >>> >>> If we have no Q type, it means that R types and U types are the same thing, >>> everything is a U type. In term of migration, it means that L types need to >>> have their semantics extended to work as U types. >> >> Yeah. We discussed this and I mentioned it in the notes, but it could use a >> deeper exploration at some point. >> >> As a minimum, there probably needs to be *some* way to indicate that a field >> can >> be flattened and may not be null. If a field has a U type, the referenced >> class >> would have to be loaded before we could tell if it's referencing a value >> class >> or not, and that's costly. > > The L type reference a class that is tagged with ACC_VALUE, so the VM knows > if a type is a value type or not.
The VM knows *after the class is loaded*. Like I said, that's costly, and forces class loading where it didn't used to happen, because every L type *might* refer to an ACC_VALUE class. In the proposed design, 'Q' types may be flattened, and 'L' types never are. > BTW, an array of a class which is tagged with ACC_VALUE is not necessary > flatten, again the array might be too big, so it means that being flatten or > not is a dynamic property, thus it should not be encoded in the VM type > system as a Q-type. 'Q' doesn't mean "flattened", it means "could be flattened if the VM chooses". It's not necessarily a dynamic property—if you've loaded the class, you know whether it will be flattened or not—but it's determined statically fairly late, probably not until the interpret has run. —Dan
