Target of opportunity: remove method <vnew> and aconst_init / withfield opcodes

[Dan Heidinga]

Can one of you sketch out the bytecode sequences being proposed?  Being
able to look at some concrete "before we used <vnew>/aconst_init/withfield"
and now "we use ....." comparisons would make the proposal clearer.

For a value class like Point, with a "Point changeX(int x)" method, we used
withfield to pop an instance off the stack, create a new instance with the
updated single field, and put that instance back on the stack which allows
us to preserve our immutability without needing a constructor per field we
want to change.

Old bytecode:
Point changeX(int x) {
  aload0
  iload_1
  withfield "Point:x"
  areturn
}

What would the new bytecode do?

--Dan


On Sat, Aug 12, 2023 at 6:49 PM John Rose <john.r.rose at oracle.com> wrote:

> The header bit is not a problem because value object headers have no
> object monitor. Thus, their headers are relatively empty OC state. Lots of
> slack.
>
> In the spirit of minimizing JVMS changes I think this approa), might make
> sense. The new byte codes paired well with new Q-descriptors and new
> verifier rules. Not so much now.
>
> Also, we already built the necessary states for serialization. The
> verifier will also hide them for us in bytecode. That was a new discovery
> yesterday over burgers.
>
> > On Aug 12, 2023, at 1:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> >
> > John and I and several others had several interresting discussions
> yesterday about Valhalla,
> > one of them about the removal of <vnew> and aconst_init/withfield,
> something i've called in the past, solving the last mile issue.
> >
> > Currently, refactoring from/to a value class/identity class is not a
> backward compatible move because of the way value classes are initialized
> using the <vnew> factory method. The reason is that during the
> initialization, a class instance is mutable but the VM considers that all
> value class instances are non-mutable.
> >
> > But at the same time, in order to implement Serialization of value
> classes (exactly de-serialization), there is a need for a mechanism to tag
> value class instances as "not yet finished to be initialized", something
> John refers has the object being in larval state because the
> de-serialization first create the instance and then populate its fields. In
> the lw prototypes, this is currently implemented using Unsafe.
> >
> > I think we have the opportunity now to use the same larval protocol for
> all values classes, making them binary backward compatible with identity
> classes. With both of them using the initialization protocol, the same
> new/dup/invokespecial dance.
> >
> > In term of specification, the idea is that "new" on a value class
> creates a larval instance and the end of the constructor mark the instance
> as non-larval/true-value-instance.
> >
> > I think that using the same initialization protocol at callsite is a
> good idea. We are re-aligning the bytecode with the Java code, One thing
> wichh is currently hard to understand for our users is that currently the
> Java code is the same for a value class and an identity class but the
> generated bytecode is not binary compatible. This also go well with the
> recent move to remove the Q-descriptor, we are moving toward the goal of
> being fully binary backward compatible.
> >
> > We may want to modify the verifier to verify that "this" does not escape
> the constructor in case of a value class, but I do not thing it's a
> requirement, so it's maybe better to not do that :)
> >
> > The end of constructor is already a point where all VMs/JITs are able to
> emit codes (for store/store barrier or finalizer registration), so we are
> piggy backing on an existing concept. The only main drawback I see is that
> the header of a buffered value type has to have one bit to indicate the
> larval state and those header bits are really precious.
> >
> > regards,
> > Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230814/1e339861/attachment.htm>