----- 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. 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. > > —Dan Rémi
