Design notes for next values iteration

[Dan Smith]

> On Nov 22, 2017, at 9:42 AM, forax at univ-mlv.fr wrote:
> 
> 
> 
> ----- 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.

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