B3 ref model

[Brian Goetz]

> 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.