RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]

[Remi Forax]

----- Original Message -----
> From: "Archie L. Cobbs" <duke at openjdk.org>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Friday, October 6, 2023 8:26:34 PM
> Subject: Re: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]

> On Tue, 3 Oct 2023 23:24:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:
> 
>>> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will
>>> have to be ignored as for them to pass some changes need to be made to the
>>> verifier which still expects value classes to have factory methods (vnew)
>>
>> Vicente Romero has updated the pull request incrementally with one additional
>> commit since the last revision:
>> 
>>   minor fixes
> 
> I still think that having a magic `static T.<new>:(…)T` factory method for every
> `T.<init>:(…)V` method, which would do the `new`, `dup`, `<init>` dance behind
>  the scenes, would be a good idea.[^1]
> 
> --------------------------------------------------------------------------------
> 
> This would allow the `new` bytecode to eventually go the way of `jsr`/`ret`, and
>  `<init>:(…)V` would become a method called by the VM, similarly to
>  `<clinit>:()V`, except that `<init>:(…)V` allows calling `super.<init>:(…)V`.

Hello,
a lot of us in the Valhalla EG would like to deprecate the "new dup init" dance. But if you take a closer look, this is really hard in term of engineering for a small return.

Unlike jsr/ret, the instance construction/initialization protocol requires cooperation of both the call site and the declaration site.
What you are suggesting required to update both sites but because Java allows separate compilation, we will have to deal with all 4 configurations (none are updated, they are all updated, call site only is updated, declaration site only is updated).

If you try to run some examples that are using inheritance like you have 3 classes that inherits one from the other and only the class in the middle is recompiled, it rapidly becomes a nightmare.
And you have update all the consumers of bytecodes, not only the VM but also javac, a debugger, a Java agents, etc. 

So what you are asking is the size of moving from Python 2 to Python 3. It's not going to happen.

regards,
Rémi

> 
> 
> [^1]: This has been suggested in:
> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002342.html
> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002343.html
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/valhalla/pull/934#issuecomment-1751223717