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

[Andrew Dinn]

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