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

[Andrew Dinn]

On 25/07/17 14:10, Doug Lea wrote:
> 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.

Thanks, Doug, for clarifying what is at stake in this specific case vs
the more general problem that might be faced.

> Are there any other cases of interest where full consume mode
> is needed/desired?
I cannot answer your last question. However, it seems clear to me that
the point in question in Coleen's proposed fix falls under the specific
category of problem you describe above i.e. the two addresses whose
visibility is ordered by the release barrier are such that the second
cannot be accessed without loading and dereferencing the first.

I can perhaps imagine a processor which fails to respect that sort of
dependency existing on a Research Lab blackboard but I doubt we will
ever see the like embodied in silicon. So, I don't think we need to fear
any consequences if we let this change set go through without a load
barrier. I'll defer to other reviewers if they wish to disagree.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander