[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

Some of this PR is based on wrong-headed misunderstanding
of the term "structure tearing", and some is based on a difference
of opinion about what's best for the end-user.  The part I would
prefer to keep makes more clear the connections between
the existing "compound-atomic" APIs, all of which have `Atomic`
in their names, and the necessary new feature for multi-component
access atomicity, which should *not* have `Atomic` in its name.

Please reformulate to be less disruptive of existing decisions,
or change the decisions by persuasion.

It looks to me like the only useful change proposed here
is a reformulation of the trailing comment in NonTearable.java,
relating it more usefully to the Atomic ™  APIs.

A better exposition of "structure tearing" would be welcome too.
The discussion of transient vs. permanent failure is illuminating.

I think "out of thin air" is a useful description of what a programmer
sees on such a failure, since the structure as a whole was never
constructed by any thread.  I realize that it might distract someone
familiar with the JMM literature.  Perhaps a less confusing term
would be "a composite value never created by any thread", but
"out of thin air" (in scare quotes) seems descriptive to me at least.

The material point for the end user is that structure tearing can
lead to the appearance (temporary or permanent) of primitive
values which were never created by any thread.  Giving a way
to control that phenomenon ("out of thin air" structures, created
by races if not speculation) is the motivation for this feature.

Notice that this problem is new to primitive classes.  There is
no corresponding notion for identity classes which are
configured like primitives, and therefore have all final fields.
The JMM guarantees safe publication for those, which means
no rogue states are ever visible in *those* multi-component
structures.  But when multi-component primitives are inlined,
the JMM needs a *new* guarantee in the place of safe publication.
Non-tearability is the term we have chosen for this.

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

Changes requested by jrose (Committer).

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