JVMS changes for JEP 401

[-]

On a side note, does VM spec require all strict fields to be already
assigned via putfield (i.e. no missing assignment, even ones with default
zero values) before a super constructor call? (This doesn't affect the
correctness of strict fields, as unassigned fields will just have default
zero values published)
If it doesn't, having no restriction on strict assignment for
this-delegating constructors would be a great step toward simplification;
but if it does, I think the super-calling constructor has diverged from
this-calling constructor enough that adding another
no-assignment-in-this-caller rule doesn't hurt that much.

On Tue, Feb 6, 2024 at 10:01 AM John Rose <john.r.rose at oracle.com> wrote:

> On 29 Jan 2024, at 10:22, Dan Smith wrote:
>
> >>
> >> 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.
>
> This might be worth a non-normative note, to the effect of, “One may
> notice that the VM may assign strict fields before this-calls in the VM.
> Java compilers do not issue putfield instructions at such points, and we do
> not expect them to do so in the future.  A special restriction on such
> assignments would add no value.”
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20240206/6e9b22f5/attachment.htm>