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

[John Rose]

On Jan 13, 2020, at 12:08 AM, Tobias Hartmann <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
> 
> Hi John,
> 
> On 24.12.19 22:36, John Rose wrote:
>> This uncovered a missing StoreStore barrier in C2, which I also fixed.
> 
> Do you know why that barrier is not added in PhaseMacroExpand::expand_allocate_common?
> http://hg.openjdk.java.net/jdk/jdk/file/f7edb9ca045c/src/hotspot/share/opto/macro.cpp#l1406

P.S. The bigger question, which I am not qualified to answer,
is, “where should the store-store barrier be introduced?”
I just found a likely spot which fixed a bug.  There could
well be similar bugs in the woodwork which have not jumped
0ut yet, which would be fixed by careful rethink of the
heap-buffering paths.

P.P.S. Just in case someone is thinking, “but value types are
*supposed* to tear; stop being so picky”:  No, it’s a real problem.

Value types are allowed to tear in user-visible heap variables
(unless marked “always atomic” via an upcoming feature).

But buffers introduced on the fly by the JVM are not user-visible
variables.  They are not even variables; they are immutable;
this strengthens my point, though doesn’t make it completely.

Allowing JVM-introduced buffers to tear, combined with the
fact that the JVM has freedom to unbuffer and rebuffer values
between any two instructions (remember deopt & reopt),
means that tearable heap buffers translates into tearing of
values which are apparently on-stack.  That’s not a workable
user experience, since even if the user is 100% determined
to avoid tearing by careful use of locks (yeah, right), there
is no relevant lock object for a heap buffer, since it’s invisible
to the user.