The Record Attribute - What does it mean to be a record at runtime?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "Chris Hegarty" <chris.hegarty at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 13 Novembre 2020 01:18:01
> Objet: Re: The Record Attribute - What does it mean to be a record at runtime?

>> For me, you are focusing on the wrong side of the time line,
>> trusted final fields should be the new normal and plain old classes are the ones
>> that are weird because they have a *weak* final fields semantics.
>>
>> So instead of saying that records, hidden classes, anonymous classes (and soon
>> primitive object classes) are special, the VM should say that plain old classes
>> are the outlier.
> 
> In an ideal world, yes, although I don't think wishing that does
> anything for our current issue(s) with records.
> 
> Btw, for the records, the work described here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8233873
> 
> iis what's required to enable final field optimization _safely_ (stress
> this word many times, please) for _all_ classes. But that's besides the
> point.
> 
> The point in my email is that just attaching an attribute (the record
> attribute) to a class doesn't magically remove the safety concerns
> associated with trusting final fields (some of which are captured in the
> above RFE). With the current mechanism for trusted final fields we still
> have to double check that trusted finals cannot be updated. So there has
> to be a symmetry between the logic granting the trusts and the logic
> which keeps the platform on a safe ground by rejecting final fields updates.
> 
> In the current situation, I'm not sure the symmetry is there (at least
> not in all the code paths), and the logic to prevent reflective field
> update is borderline unspecifiable (*) and, even w/o considering that,
> inconsistent with what the implementation does, so it should be fixed
> one way or another.

I fully agree that the codes in Field.set(), lookup.findSetter/unreflectFiedl() have to be fixed,
i disagree that this is a problem related to records.

For enums, the VM and the reflection disagree about what an enum is, and that's not an issue.
(in fact, isEnum() et getEnumConstants() also disagree of what an enum is).

The fact that there is no record access bit in the header of a class is to avoid to use one of these precious bits.
So from the VM POV, a class is a record because it has the Record attribute.

As i told Chris, i believe that the best to fix this issue is to have the VM to export a method boolean hasWeakFinalFieldSemantics(Class) that says if a class allows final fields to be set or not.
And to fix the spec of Field.set(), lookup.findSetter/unreflectFiedl() to say that only plain old classes and enums allow their final fields to be set.

> 
> Maurizio
> 
> (*) Field::set doesn't fail when Class::isRecord returns true (which is
> what we currently specify) but when the class the field belongs to has
> the Record attribute. Should we add that to the javadoc ?

that only POJO and enums final fields can be set.

Rémi

> 
>>
>> With that, the JLS definition of a record doesn't need to leak into the JVMS.
>>
>>> Maurizio
>> Rémi
>>
>>> On 11/11/2020 02:39, Dan Smith wrote:
>>>>> On Nov 10, 2020, at 1:51 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>>>
>>>>> My issue is with how the VM determines whether a field is trusted or not. The VM
>>>>> trusts fields in (among other types) “record” classes. So what is a record
>>>>> class to the VM?   (that is the question that I am trying to resolve) - the
>>>>> answer is not in the JVMS ( which is fine ).
>>>> Suggestion: the VM shouldn't bother to provide any definition for "record
>>>> class". That's up to Java language compilers and reflection (which should be in
>>>> agreement).
>>>>
>>>> Instead, can't we say the VM trusts fields in classes that have a Record
>>>> attribute? Who cares whether those classes are "real" records or not? (I may be
>>>> missing something because I don't fully understand the concept of "trusted
>>>> final field", but it seems to me like HotSpot has a lot of freedom to decide to
> >>> trust or not trust whatever fields it wants.)