RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException
David Holmes
david.holmes at oracle.com
Fri May 26 09:20:19 UTC 2017
Hi Andrew,
On 26/05/2017 6:26 PM, Andrew Haley wrote:
> On 26/05/17 03:20, David Holmes wrote:
>> Any variable passed to an OrderAccess, or Atomic, function should be
>> volatile to minimise the chances the C compiler will do something
>> unexpected with it.
>
> That's not much more than paranoia, IMO. If the barriers are strong
> enough it'll be fine. The problem was, I suppose, with old compilers
> which didn't handle memory barriers properly, but we should be moving
> towards standard ways of doing these things. Standard atomics have
> been available since C++11 (I think) and GCC has had support since long
> before then.
The issue isn't just the barriers that might be involved inside
orderAccess methods. If these variables are being used in racy lock-free
code then they should be marked volatile to ensure other compiler
optimizations don't interfere. Perhaps that is paranoia, but I'd rather
a little harmless paranoia than try to debug what might otherwise go wrong.
Regardless of anything else the declaration(s) of _f1 are "wrong" under
our existing approach to lock-free code. Fixing those declarations may
or may not make any difference to the observed spurious NPE problem.
The backport of the improved compiler_barrier is a separate issue.
> Maybe in the JDK10 timeframe we can look at upgrading the compilers
> for all platforms.
I have no doubt we will upgrade compilers, but whether we try to use
C++11 features/APIs is a different matter. IIRC there are already some
open RFEs to look into this.
Thanks,
David
> Andrew.
>
More information about the jdk10-dev
mailing list