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

[Andrew Haley]

On 27/05/17 10:10, Volker Simonis wrote:
> On Fri, May 26, 2017 at 6:09 PM, Andrew Haley <aph at redhat.com> wrote:
>> On 26/05/17 17:03, Volker Simonis 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.
>>
>> Yes, but so do compiler barriers.
> 
> Please correct me if I'm wrong, but I thought "compiler barriers" are
> to prevent reordering by the compiler. However, this is a question of
> optimization. If you have two subsequent loads from the same address,
> the compiler is free to do only the first load and keep the value in a
> register if the address is not pointing to a volatile value.

No it isn't: that is precisely what a compiler barrier prevents.  A
compiler barrier (from the POV of the compiler) clobbers all of
the memory state.  Neither reads nor writes may move past a compiler
barrier.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671