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

[Andrew Dinn]

On 25/05/17 15:38, Andrew Haley wrote:
> Well, that's wrong.  The bug is in OrderAccess::release_store_ptr(),
> which must not allow this reordering.  Put a proper release barrier
> in there before the store, and all will be well:
> 
>     __atomic_thread_fence(__ATOMIC_RELEASE);
> 
> There's really no need to make both fields volatile.  And to do so
> leaves a lurking bug for any other unsuspecting user of
> release_store_ptr().

Oops. Apologies for this but I misread the gdb output when I ran this on
jdk10. The re-ordering of the store instructions is not happening in
jdk10 or jdk9.

It does happen on jdk8 (that probably explains why the reproducer only
manifests the NPE in jdk8 :-).

The jdk10 implementation of release_Store_ptr has indeed already been
reworked to insert a compiler barrier (using "asm volatile memory") but
not a memory store barrier.

I retract this patch. The problem with jdk8 still exists. It probably
needs fixing by backporting the changes to the store_release etc.

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