Change non-tearable nomenclature to access atomic

[Doug Lea]

I have seen the term "Unitary" used in this context. Basically a synonym 
for atomic, but doesn't carry the conventional interpretation of 
necessarily supporting RMWs.

On 6/14/21 7:52 PM, Kirk Pepperdine wrote:
>>
>> Not that my vote counts but I didn’t find NonTearable to be all that terrible (pun intended). At first I was thinking primitive tearing but a wee bit of reading cleared that up. I did a little splunking about in the OED and nothing really stood out as being more appropriate or offered any where near the level of clarity that this name does.
>>
>> Kind regards,
>> Kirk
>>
>>
>>> On Jun 14, 2021, at 3:27 PM, Brian Goetz <briangoetz at openjdk.java.net> wrote:
>>>
>>> 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
>>> I am not married to the term `non-tearable`, and happy to consider alternatives, but `atomic` is definitely a move in the wrong direction.  John outlined most of the arguments, but basically: atomicity, in the context of user-visible Java APIs, is generally reserved for describing atomicity of user-level mutative operations, including read-modify-write operations (e.g., CAS, incrementAndGet, etc.)  This is the A from "ACID".  (Our friends in the database community might call these operations _serialized_, but as that also means something else in Java, we won't call it that either.)
>>>
>>> So, happy to consider alternatives to non-tearable (it was just the best we came up with at the time), but I think `Atomic*` will definitely send the wrong message about what operations are atomic relative to each other.
>>>
>>> -------------
>>>
>>> PR: https://git.openjdk.java.net/valhalla/pull/428
>>
>>