[lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable" nomenclature to "access atomic" [v2]
briangoetz at openjdk.java.net
Mon Jun 14 22:27:03 UTC 2021
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.
More information about the valhalla-dev