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

[John Rose]

On 14 Aug 2023, at 7:35, Dan Heidinga wrote:

>
> If I'm following correctly, changing one field requires stacking all the
> fields and calling the constructor?

Yes.  Just as we do today with Java records.

I expect the JIT will pay extra attention to constructor calls which pass through previous field values, for all fields but one, and DTRT.  But I also hope that we will build a “reconstructor” mechanism into the VM, where a constructor-like method body executes, not against a blank instance (just produced by “new”) but against a freshly buffered clone of an existing instruction.  (That’s pretty much what I mean, at the VM level, whenever I mention “reconstructors”.)  A “wither” formulated as a reconstructor would have exactly one “putfield” (in the new design), or formulated as a static factory it would have exactly one “withfield” (in the old design).  That feels like design parity to me.

> From a VM perspective withfield is nice but as I dig through my notes, I
> don't see any notes on how we'd expose it in the language.  All the
> examples I'm finding are either directly generating the withfield bytecode
> or java source that shows the fields passing through a constructor.  Do we
> have a model on how javac would generate withfield or have we already
> defaulted in the ctor model?

We have already defaulted to the ctor model.  The withfield was seen as a demonstrably clean and incremental operation, useful at present for constructors and in the future for reconstructors (or just withers, which are a special case).  But if putfield is just as good, why build a new bytecode?