> 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.
> 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 ?
Preload contains names of classes, not types. At the time Container is
compiled, the compiler will find Prim, and will look at whether it is a value
type or not, and maybe put something in Preload. Of course the class could
migrate between compile and runtime, in which case we’ll lose some flattening
we might have had with a consistent compilation. Not a big deal.
