RFR (S) 8182397: Race in field updates when creating ArrayKlasses can lead to crash

[Doug Lea]

On 07/25/2017 07:13 AM, Erik Österlund wrote:

>> OrderAccess could support consume tomorrow: that's up to us.
> 
> We could indeed. But then we got to do that first, and replace
> load_acquire with load_consume, rather than with normal loads.

A full spec of C++ consume mode is challenging (and still in progress).
But it is possible to take the easier path underlying JDK9 modes,
that (implicitly) deal only with pointer dereferences:
As in: T* p = x; V v = p.field; where x is some shared variable.

If a reader cannot have a valid value for the field of an
object (or struct etc) without knowing its address, then it
cannot reorder these statements. The usual reason is that the
reader cannot have ever seen that address before, at least not since
some other fence at least as strong as acquire. (Another way
to say this is that neither compilers not processors may act as
if they speculate addresses that they have never seen before.
If this were not true, then secure computing would be just about
impossible.) Correctness is usually easy to check in particular cases,
but nearly impossible in the general case (you may need global
information-flow analysis).

This is close to the linux "ACCESS_ONCE" approach, and is
also the idea underlying Java final fields. See
  http://gee.cs.oswego.edu/dl/html/j9mm.html

Using C++-atomic-relaxed/Java-opaque can be used to express this,
but in the vastly most common case where all subsequent reads will
return the same value (at least up until some other fenced event),
just plain loads suffice.

Are there any other cases of interest where full consume mode
is needed/desired?

-Doug