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

[Volker Simonis]

On Sat, May 27, 2017 at 4:45 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On May 26, 2017, at 12:03 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Volatile not only prevents reordering by the compiler. It also prevents
>> other, otherwise legal transformations/optimizations (like for example
>> reloading a variable [1]) which have to be prevented in order to write
>> correct, lock free  programs.
>>
>> So I think declaring the variables involved in such algorithms volatile is
>> currently still necessary.
>
> Seems like the thing to do would be to use Atomic::load instead of a
> bare reference.
>

Yes, but Atomic::load is not overloaded for oop/narrowOop and the
naming doesn't really express what we want to achieve. The proposed
fix was to change 'oopDesc::load_heap_oop()' such that it casts its
plain pointer argument into a 'pointer to volatile' argument.
Unfortunately, I've just realized, that this fix (i.e. JDK-8129440
[2]) was never pushed which I think is bad (we have it in our SAP JVM
since long time). The comment on 'oopDesc::load_heap_oop()' clearly
states that it is "Called by GC to check for null before decoding".
This obviously can not work reliably if the oop is reloaded a second
time after the null check (and before the decoding). I don't see how a
compiler barrier could help here because this is not a question of
reordering.

[2] https://bugs.openjdk.java.net/browse/JDK-8129440