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

[Andrew Haley]

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.

> So I think declaring the variables involved in such algorithms
> volatile is currently still necessary.

IMO, only if compiler barriers don't work; and that implies broken
compilers.  But from the responses I've seen, the assumption is that
the compilers used to build HotSpot are broken.

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