RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException
Andrew Haley
aph at redhat.com
Fri May 26 16:09:33 UTC 2017
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
More information about the jdk10-dev
mailing list