JVMS changes for JEP 401

[Remi Forax]

----- Original Message -----
> From: "Clement Cherlin" <ccherlin at gmail.com>
> To: "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.org>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, January 29, 2024 4:30:01 PM
> Subject: Re: JVMS changes for JEP 401

>> On Tue, Jan 23, 2024 at 7:11 PM Dan Smith <daniel.smith at oracle.com> wrote:
>>>
>>> I've posted a revised spec change document for JEP 401, Value Classes and
>>> Objects, here:
>>>
>>> https://cr.openjdk.org/~dlsmith/jep401/jep401-20240116/specs/value-objects-jvms.html
> 
> [snip]
> 
>>> - The 4.9.2 rule about ACC_STRICT is hard to parse, will be rephrased somehow
>>>
>>> - 2.4 should say more about "sameness" as it relates to "identity"
> 
> On Tue, Jan 23, 2024 at 8:15 PM - <liangchenblue at gmail.com> wrote:
>>
>> Hi Dan,
>> Thanks for sharing this document! It looks great!
>> There's a typo in section 2.4, where the definition of "element type" for an
>> array type is accidentally removed.
>>
>> The reference to the "start of object construction" can probably be changed to
>> "before the super-call," taken from John's "Constructive Classes" essay. [1]
>> The 4.9.2 rule is correct;
> 
> Unless I'm mistaken, the rule in 4.9.2 is not correct.
> 
> From the proposal:
>>> An instance field of this declared in the current class with its ACC_STRICT flag
>>> set may be assigned by a putfield instruction occurring in an instance
>>> initialization method only if another instance initialization method has not
>>> yet been called.
> 
> As I understand the current design intent, a constructor that calls
> 'this' is forbidden from assigning to a strict field, because that
> will lead to a duplicate assignment in a constructor that calls
> 'super'.
> 
> This language appears to say the opposite. It seems to state that only
> the first constructor of the current class can assign the class's
> strict instance fields. If that is the case, then further constructors
> (including the one that calls 'super') are forbidden from assigning to
> strict instance fields.

Hello,
the problem is not duplicate assignment, as you said that part of the spec allows that,
the problem is assignment of final fields after a call to super() or this() because when the assignment occurs, 'this' may have already leaked to another context.

For example, currently you can write

  class B extends A {
    final int x; 
   
    B() {
      super();
      // just after the call to super() (or this()), the parameter this can be used even if it is not fully initialized
      System.out.println(toString());   // here calls to this.toString() ooopsy ! 
      x = 3;
    }
  }

With _strict_ final fields, they must be inialized *before* the call to super() / this(), so before a user is allowed to use 'this' as a parameter

  class B extends A {
    _strict_ final int x; 
   
    B() {
      x = 3; // okay !
      super();
      System.out.println(toString());  // no problem 'this' is fully initialized at that point 


      x = 3;  // not legal anymore
    }
  }


Note: we need this feature for value types and we think it's also great to have it for identity class because if all final fields are strict, there is no way to have an unsafe initialization. This is a long standing problem when you have multiple threads that access to the same instance. For a thread-safe class, before this change the idea was to not leak 'this' and now the idea is that if you leak 'this' it is innocuous because all strict final fields have already been initialized.

> 
>> perhaps we can be more explicit, that such a putfield can only exist in an
>> <init> that calls a direct superclass's <init>, and the putfield must exist
>> before such a super-call.
> 
> I believe those are the correct requirements.
> 
>> [1] https://cr.openjdk.org/~jrose/jls/constructive-classes.html
> 
> Cheers,
> Clement Cherlin

regards,
Rémi