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

[Vitaly Davidovich]

I agree with David.

The spec and Doug's cookbook are silent on volatiles inside constructor,
whereas both call out ctor + final fields explicitly.  Therefore, if we
talk about constructors like regular methods (which they are, at least for
this discussion), then there's nothing that indicates any
happens-before/freeze/ordering/whatever-we-call-it for those volatile
writes.

As for things like AtomicInteger breaking, it sounds like some code
publishes them unsafely and expects final field like treatment - seems like
a bug in those implementations.  Otherwise, it seems like VM
implementations are being adjusted to hide broken code, which is of course
undesirable.

Whatever comes out of this discussion (or wherever it moves) relevant docs
should be updated so this confusion can stop (at least for people willing
to do research).  There shouldn't be some assumption that all readers will
interpret an otherwise vague issue correctly and consistently.  If someone
goes through the analysis and deduces or "proves" that, even with current
JMM wording, volatiles get same treatment as finals, then that analysis
should be documented in said authoritative sources; that way, we can avoid
discussions like this one :).

Thanks

Sent from my phone
On Nov 26, 2013 5:57 PM, "David Holmes" <david.holmes at oracle.com> wrote:

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20131126/58f02c4e/attachment.html