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

[David Holmes]

On 27/11/2013 1:26 AM, Aleksey Shipilev wrote:
> 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.

A fundamental abstraction in the JMM is the happens-before relation. 
There is nothing in the JMM that requires that #2 happens-before #3.

> 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.

It would have been nice if that discussion has been shared with others 
and perhaps used to trigger an update to the spec if that was needed - 
something which is now impossible for JDK 8.

> I think further discussion about this should be held at c-i@, if you

No it should be on javamemorymodel-discussion at cs.umd.edu

> 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).

It is very well-known that unsafe publication can cause you to see an 
object that is only default initialized. This is fixed for objects with 
final fields, but remains true for objects with volatile fields. The JMM 
is quite clear on the special treatment of only final fields.

>> 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).

Show me a happens-before relation that prohibits the reordering.

>
>> 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

Of course the spec would need updating if volatiles are to get the same 
special treatment as final fields!

David
------

> 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.
>