Fwd: RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException (original) (raw)

Andrew Dinn adinn at redhat.com
Fri May 26 08:29:32 UTC 2017

On 26/05/17 02:04, David Holmes wrote:

On 26/05/2017 4:55 AM, Martin Buchholz wrote:

[+jdk8u-dev]

We've been hunting the elusive spurious NPEs as well; the following seems to be working for us (but we don't have any small repro recipe); something like this should be put into jdk8: In other words you want a backport of: 8061964: Insufficient compiler barriers for GCC in OrderAccess functions … https://bugs.openjdk.java.net/browse/JDK-8061964

Well, yes, that sounds like the 'correct' solution but ...

IIRC what stopped this from being an 'automatic' backport candidate was the potential problem of older gcc's needing to be validated.

If the 'correct' fix fails because of legacy compilers then I think my proposed change to the volatile declaration for _f1 will be sufficient to sort that out on x86 (I am assuming none of the legacy compilers will re-order volatile stores :-).

Of course, that's not enough in itself on AArch64 jdk8 (which Red Hat maintain downstream) nor on ppc jdk8 but it does no harm. This may not matter though. These two platforms must employ a compiler that is able to implement OrderAccess::release_store with the correct memory semantics because they don't provide TCO. So, I guess the legacy issue only applies to x86 in which case maybe my patch will be good enough.

What does everyone think?

regards,

Andrew Dinn

Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the hotspot-dev mailing list