[lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable" nomenclature to "access atomic" [v2]

[John R Rose]

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

src/java.base/share/classes/java/lang/AtomicAccess.java line 64:

> 62:  * If data integrity or security depends on proper construction,
> 63:  * the class should be declared as implementing {@code AtomicAccess}.
> 64:  *

This comment is useful, because it distinguishes non-tearable from the
de-facto standard notion (in the JDK) of "atomic", which pertains to
"compound operations".  Atomic compound operations relate multiple
states of a variable in a consistent sequence sequence.  This is a
strictly stronger notion than access atomicity or non-tearability.

I support adding such a comment here, but also note that its
presence in the PR is evidence that the type name should
*not* be changed to `AtomicAccess`, precisely because
users are likely to confuse *this new* use of atomic with
*existing old* uses, all of which imply the stronger concept.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/428