Design notes for next values iteration

[forax at univ-mlv.fr]

Hi Dan, 

> 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 18:24:22
> Objet: Re: Design notes for next values iteration

>> On Nov 22, 2017, at 9:42 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>> ----- Mail original -----

>>> De: "daniel smith" < [ mailto:daniel.smith at oracle.com | daniel.smith at oracle.com
>>> ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> 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 < [ mailto:forax at univ-mlv.fr |
>>>> 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.

John and Frederic said the same thing during the valhalla meeting, 3 against one, ok, i get it. 

>> 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.

My point is that for array (not fields), you can delay the decision until you create the array, so very late when at that point you have to load the class anyway. 
John said this may cause an issue with the verifier. 

For fields, i like what's you propose i.e tag the field with a modifier saying "flatennable", so the verifier and the interpreter can take the decision earlier without loading the class. 
Decoupling the type from the property, it's not a Q type anymore, it's a flattenable field that will check that the type when loaded is a value type, avoid to have to bridge between R types and Q types, so it seems the right way to deal with this issue. 

For array, if there is an issue with the verifier, we may still need Q type for that case, to encode the fact that the component of an array make the array "flatenable". 

> —Dan

Rémi