VM model and aconst_init

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 12, 2022 1:45:34 PM
> Subject: Re: VM model and aconst_init

> Both value and primitive classes use the aconst_init / withfield initialization
> protocol. The former is an L-type (QOptional is illegal); the latter uses Q
> types for initialization.

> Value classes
> -> are L types
> -> which are references
> -> references can be null
> -> VM manages where the nullity bits are

> so for value classes, there has to be some way of starting the ball rolling with
> an uninitialized, but non-null, value. We can then modify the fields (but not
> the nullity) with `withfield`.
Ok, but in that case how the verifiers know if aconst_init generate a Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and not a descriptor as parameter. 

Rémi 

> On 1/12/2022 7:31 AM, Remi Forax wrote:

>> I've some troubles to wrap my head around those two sentences

>> """
>> aconst_init is the analogue of new for value objects; it leaves a reference to
>> the initial value for a value class on the stack. This initial value is
>> guaranteed to not be equal to null. The sole operand of this bytecode is a
>> reference to a CONSTANT_Class item giving the internal binary name of the value
>> class (not its Q descriptor).
>> """

>> and
>> """
>> Both withfield and aconst_init return a Q type if and only if their class is a
>> primitive class.
>> """

>> The second is ambiguous because it's not clear if aconst_init can return a
>> L-type. I suppose it can not but this is not clear at all.

>> If this is the case, what is the use case for withfield taking a L-type as
>> parameter ??

>> regards,
>> Rémi