JVMS changes for JEP 401

[Clement Cherlin]

On Mon, Jan 29, 2024 at 12:23 PM Dan Smith <daniel.smith at oracle.com> wrote:
>
> On Jan 29, 2024, at 9:06 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> ----- 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.
>
>
> Right.
>
> There is a *language* rule that final fields must not be assigned more than once. (Specifically, they must be definitely unassigned before their assignment; we'll add a rule that final fields must be definitely assigned before a 'this()' call.)
>
> In the *JVM*, the only new thing we're guarding against is assignments after the constructor call. All assignments before a constructor call, duplicate or not, are allowed.

In that case, the wording is indeed very confusing. It appeared to me
to say that there can be no assignments to strict fields in a
constructor of the current class called *from* another constructor of
the current class. I see now that interpretation was wrong, but to me
it was the most plausible interpretation of the text.

The correct interpretation is that strict final fields can be assigned
to in a given constructor before a call *from* that constructor to any
other constructor (and not afterwards).

The intended meaning is (assignment to strict field may occur) only if
((call to (another instance initialization method) from (this instance
initialization method)) has not yet occurred), but it read to me as
(assignment to strict field may occur) only if ((call to (another
instance initialization method) from (any method)) has not yet
occurred).

I hope I've made it clear where the confusion lay and what could stand
to be clarified.

Cheers,
Clement Cherlin