[DarkNova6]

You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform.

This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.

[joe_mwangi]

Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.

[DarkNova6]

The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.

[germandiago]

What is terability in this context? Not a Java expert but 20 years coding and did not hear of this.

[alasr]

From Valhalla's design notes[0]:

> For the primitive types longer than 32 bits (long and double), it is not guaranteed that reads and writes from different threads (without suitable coordination) are atomic with respect to each other. The result is that, if accessed under data race, a long or double field or array component can be seen to “tear”, where a read might see the low 32 bits of one write, and the high 32 bits of another. (Declaring the containing field volatile is sufficient to restore atomicity, as is properly coordinating with locks or other concurrency control.)

... ...

[0] - https://openjdk.org/projects/valhalla/design-notes/state-of-...