RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException

[Andrew Haley]

On 30/05/17 11:57, Erik Österlund wrote:

> The issue is not whether an algorithm depends on IRIW or not. The
> issue is that we have to explicitly reason about IRIW to prove that
> it works.  The lack of IRIW violates seq_cst and by extension
> linearization points that rely in seq_cst, and by extension
> algorithms that rely on linearization points. By breaking the very
> building blocks that were used to reason about algorithms and their
> correctness, we rely on chance for it to work...

I've been thinking about this some more, and one thing you said has
been baffling me.  I don't think that I have come across anywhere in
HotSpot that uses seq_cst internally, and I don't think there is even
any support for it in OrderAccess.  The only thing that I know of
where we actually need seq.cst is in the C++ interpreter and JNI's
support for volatile fields, and there we simulate seq.cst by using
release_fence; store; full fence.  But we could do that with the
seq.cst C++11 functions instead.

Of course I have a motive for digging into this: I'm the lead of the
AArch64-port project.  That processor (uniquely?) has real support for
seq.cst, and it'd be nice to use it without throwing a full fence at
every volatile store.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671