RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

[Aleksey Shipilev]

Hi Vitaly,

On 11/26/2013 05:46 PM, Vitaly Davidovich wrote:
> I'm not sure I understand your reasoning in the example you gave.  If we
> treat constructor like regular method, we have this sequence:
> 1) alloc memory
> 2) assign volatile field (constructor)
> 3) assign reference
> 
> So what in the spec says step 3 cannot move above step 2? 

Nothing explicitly. Well, nothing in spec explicitly forbids it either.
Because JMM is *not* specifying what reorderings are allowed/forbidden.
The knowledge about the allowed/forbidden reorderings can be *derived*
from JMM as spec-ed. JMM specifies what consitutes the valid execution.

The sketch I outlined show that the only valid executions under the JMM
yield only the effects which "publish" the value written into the
volatile field in constructor. That is the same sketch we settled on a
year ago discussing this very issue with Martin, Goetz, and Doug. At
that time it was a consensus the correct behavior of volatile stores in
constructors is consistent with the final field semantics.

I think further discussion about this should be held at c-i@, if you
want more rigorous discussion JMM-wise. I will also gladly retract my
sketch and fix/remove the offending tests in jcstress if proven wrong,
although it would be suprise me, because this effectively means many
concurrent programs I saw are royally fubar-ed (AtomicInteger initial
value is only the tip of the iceberg).

> Also, suppose the example class has many fields, but
> only one is volatile - what then? Basically, A and A.f are two separate
> memory locations (one is computed as offset from other) and I don't
> quite get why the reordering above is not possible with constructors,
> which is just a method anyway (unless it gets some special treatment).

Please stop saying "reordering" if you want to answer the advanced JMM
question. In JMM terms, you have to ask if there are valid executions
which yield the default value for the non-volatile field. It's hard for
me to answer this question at this point (sigh).

> If volatile gets same treatment as final, then may as well update
> spec/Doug's cookbook to dispel the misconception.

I don't think spec needs updating. Cookbook might need the update, but
keep in mind that JSR 133 cookbook *is not* the JMM, it is (vague)
*interpretation* of JMM. Way too many troubles are coming from the fact
people get comfortable with JSR 133 Cookbook, and extend that comfort to
the belief they understand the Java Memory Model. I've learned for
myself that's the way the dragons lie.

-Aleksey.