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

[Kim Barrett]

> On May 26, 2017, at 12: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.
> 
>> 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.

Compiler barriers don't work if they aren't present. And for TCO
systems, that problem exists in jdk8. It was Erik O's jdk9 changes
that introduced compiler barriers. Before then, in code like the
following:

  x = new_x;
  OrderAccess::release_store(&y, new_y);

on TCO systems, the compiler was free to move the store of x after the
store of y if x is not volatile, because there is no compile barrier
in the release_store. Old compilers tended to treat volatile accesses
as stronger constraints than required by the standard. Newer
compilers, not so much. Hence the sprinkling of volatile pixie dust.
It might be worthwhile backporting the compile barriers to jdk8.

It's a separate question whether y needs to be volatile. In that
snippet, strictly speaking, it doesn't, as the release_store parameter
takes care of that. However, there's been a sort of informal use of
volatile declarations to flag such variables are "interesting" and as
a sort of marker for future std::atomic<> or the like.