Design notes for next values iteration

[forax at univ-mlv.fr]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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 <forax at 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