RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Tobias Hartmann" <tobias.hartmann at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Lundi 22 Juillet 2019 08:01:37
> Objet: Re: RFR(XS): 8228367: [lworld] Constant, null-free inline type fields should be treated as flattenable

> Hi Rémi,
> 
> On 19.07.19 17:02, Remi Forax wrote:
>> The scalarization has nothing to do with the fact of being flattenable or not,
>> the flattenability is a storage property so for value in fields or array
>> elements, not for value on the stack.
>> 
>> Being a null-free inline type is enough, you do not have to check if the fields
>> are flattenable or not.
> 
> Yes, sure. But this change is about VM/JIT internal code that attempts
> scalarization when creating
> the C2 IR for loading a constant inline type field with an inline type holder.
> And here the term
> "flattenable" is currently used interchangeably with "null-free". That's
> actually not specific to
> the JIT, but just how the VM propagates inline type field specific information
> internally.
> 
> Basically, we have three relevant field states:
> (1) !flattenable && !flattened => !null-free, !flat, !inline type field
> (2)  flattenable && !flattened =>  null-free, !flat,  inline type field
> (3)  flattenable &&  flattened =>  null-free,  flat,  inline type field
> 
> The JIT will attempt scalarization for (2) and (3).
> 
> This simplification will change as soon as there is a possibility to declare
> inline type fields that
> are null-free and !flattenable (or !null-free and flattenable, once we have
> support for null-default
> inline classes).

for the former, null-free && !flattenable, by definition you don't want to scalarize it,
but for the later, null-default, i don't see why it should not be scalarized.

IMO, a null-default inline class acts at runtime as a null-free inline class but with an additional special nullcheck when accessing a field, doing a method call, etc.

> 
> Best regards,
> Tobias

regards,
Rémi