[External] : Re: We have to talk about "primitive".

[Brian Goetz]

It took us a while to unravel this one, but I think we did.

The JMM says that loads and stores of references, and of 
32-bit-and-smaller primitive values, are atomic with respect to other 
loads and stores of the same variable.  This means that you'll see a 
valid value, though it could be a stale one.  For 64 bit primitives, it 
is treated as 2 32 bit loads, which are individually atomic.

The initialization safety guarantees -- that you see correct values of 
final fields even when loading a reference with a race -- rests on the 
atomicity properties above.

What this says is that tearing/non-tearing is a property of 
reference-vs-primitive-ness; accessing a (fat) value through a reference 
gives you *more guarantees* than accessing it directly. 
(Correspondingly, this has more costs.)

All of this is to say, as I think you are saying: primitives of a 
certain size were always tearable, and they still are; references never 
were, and they are still not.

> As for tearability: from /this/ perspective 64-bit values are already 
> technically tearable, so nothing new here. It's from a different 
> perspective, that of writing a class, where expectations have to be 
> weakened.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20211215/2b2e4b66/attachment.htm>