> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr>, "valhalla-spec-experts" > <valhalla-spec-experts@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
