for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

[Florian Weimer]

* John Rose:

> http://cr.openjdk.java.net/~jrose/values/atomic-8236522

NonTearable says this:

  38  * <p> An inline instance of multiple components is said to be "torn"
  39  * when two racing threads compete to update those components, and one
  40  * thread updates some components while another thread updates other
  41  * components.  The resulting inline value stored in the heap might be

I think this description is incorrect: a single writer, single reader
scenario (with final fields in the inline class even) can also result
in invalid values.  See “Inline classes and the memory model” posted
today; failed to spot the relevance of this older thread.

I think the actual goal here is to preserve the property that data
races cannot observe out-of-thin-air values, like it is impossible
with a subset of the primitive types?  And also to support some
concept of safe publication for inline classes?