B3 ref model

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Tuesday, April 26, 2022 4:12:43 PM
> Subject: Re: B3 ref model

>> so if we have
>> 
>> primitive class Prim {
>>  long value;
>> }
>> 
>> class Container {
>>  LPrim; prim;
>> }
>> 
>> and Prim has been loaded before Container is seen by the VM, the VM can not
>> decide to flatten LPrim; to a long + a bit for nullability because the VM has
>> to ensure atomicity even if the user has declared Prim as a primitive class.
> 
> Of course, we don’t put L or Q in the source code, but we put .val or .ref which
> translates appropriately.  If you have a field of type X.ref, the compiler
> should put X in the preload attribute.  If this doesn’t happen, then yes, there
> will be no flattening.  If it does happen, there may be flattening.

but the VM has already loaded Prim, it knows that its a B3.

The preload attribute is to pre-load if the VM does not know if it's a value type or not.

It seems you want to restrict the VM to take local decisions independently of the classes already loaded ?

For me, L-type means: if you do not already know, you will discover later if it's a B1/B2/B3 when the class will be loaded.
The preload attribute means: if you do not already know, you should load the class now (at least when you want to take a decison based on the class being a B1/B2/B3 or not).

A L-type does not mean, it's a pointer and it's always be a pointer, because if a user has chosen a class to be a B3, the VM should do whatever is possible to flatten it, even if the declared type is a L-type.

By example, if you have a code like this
  record Holder(Object o) { }
  primitive record Complex(double re, double im) { }

Holder holder = new Holder(new Complex(2., 3.));
...  // more codes 


The VM may found that "holder" escapes but at the same time that Complex is a B3, in that case the instance of Holder is allocated on the heap but the instance of Complex can be flattened inside the heap representation of Holder. In this example, there is no QComplex; in the bytecode of Holder, there is no Preload attribute too, the VM knowning that a Complex is a B3 is enough.

And i'm not suggesting that it's what a particular VM should do that, just that a VM should be able to do that.

Rémi