for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity
john.r.rose at oracle.com
Mon Jan 13 21:05:49 UTC 2020
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?
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
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.
More information about the valhalla-dev