[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

Thank you for explaining to all of us about word-tearing, but that seems to be moot in the context of this PR.  This feature (`NonTearable`) is about *structure tearing*, which is a distinct concept.  Hence the different name, as you might have noticed.

There is also a reason for not using the term "atomic".  Indeed it was my preference, but Brian (as he can explain himself as well) has at least two good reasons for avoiding that term, and going with the new term `NonTearable` (as well as the underlying exposition about the *new* phenomenon of structure tearing).

(The term non-tearable is in fact closely synonymous with the term atomic, which literally means non-cuttable.)

A couple of reasons *not* to use "atomic" here:  First, the term is already taken, in the package `java.util.concurrent.atomic`, with classes like `AtomicInteger`.  Users would be faced with different `AtomicFoo` types, leading to needless pedagogical burden.  (It doesn't matter that a dozen JMM experts would be made happier by using a common term for a common underlying notion.)  Second, although you nicely propose `AtomicAccess` as a good and correct term, the basic meaning of Atomic, at the user level, is already *stronger* than atomic access:  It implies not only that structures won't tear, as longs and doubles can tear in Old Java, but also the word "atomic" implies some kind of state-to-state consistency, such as is provided by CAS or atomic add.  Yes, I see that "access" in "atomic access" is a clever way of backing away from state-to-state consistency claims, but it's too subtle.  A new term is needed for the weaker concept.

In other words, for API design, let's keep using the term Atomic for the stronger (more useful term) and NonTearable for the weaker idea of a atomic-for-single-acceses-only.  That's what you are seeing with the term "non-tearable", and what I hope you can also see with the development of the not-really-so-weird discussion of "structure tearing".

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

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