B3 ref model

[forax at univ-mlv.fr]

----- Original Message -----
> From: "daniel smith" <daniel.smith at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Tuesday, April 26, 2022 2:15:17 AM
> Subject: Re: B3 ref model

>> On Apr 25, 2022, at 3:08 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Ok, maybe i've not understood correctly how B3 model works,
>> for me being a B3 is a runtime property, not a type property.
>> 
>> By example, if there is an Object but the VM knows the only possible type is a
>> B3 and the value is not null then the VM is free to emit several stores,
>> because it's a B3, so tearing can occur.
>> 
>> Said differently, B3 allows tearing, so B3.val and B3.ref allow tearing.
>> 
>> If i do not want tearing, then B3 has to be stored in a field volatile or i have
>> to declare the class as a B2.
>> 
>> Did i get it right ?
> 
> The model we've designed is that B3 instances can be represented as *objects* or
> *primitive values*. Objects enforce atomicity as part of their encapsulation
> behavior; primitive values do not. Whether something is an object or not is a
> property of types—ref and val at the language level, L and Q at the JVM level.

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.

I really dislike this semantics, for me, we are re-creating the kind of troubles we have with escape analysis but for field storage.

And how the Preload attribute is supposed to work in that context, given that it declares that a L-type is in fact a Q-type ?

Rémi