Release store in C2 putfield

Andrew Haley aph at
Wed Sep 3 18:02:52 UTC 2014

On 09/03/2014 06:47 PM, Aleksey Shipilev wrote:
> On 09/03/2014 09:00 PM, Andrew Haley wrote:
>> On 09/03/2014 05:49 PM, Aleksey Shipilev wrote:
>>> Why is a simple store is sufficient here for AArch64? Do the stores ordered on AArch64 (I thought not)? I thought the "RC" part in "RCsc" only applies to explicit synchronization instructions.
>> I discussed this with Peter Sewell, and it's explained in his (co-authored) paper "A Tutorial Introduction to the ARM and POWER Relaxed Memory Models" at in Section 4.1, "Enforcing Order with Dependencies"
>> In the AArch64 spec, we have:
>> B2.7.2  Ordering requirements
>> If an address dependency exists between two reads or between a read and a write, then those memory accesses are observed in program order by all observers within the shareability domain of the memory
>> So, an address dependency and a DMB when an object is created is all we need.
> Okay, I read that paper from Sewell et al. before. I don't quite believe this is about "reading" the constructed objects, and so I don't see how address dependencies are applicable here.

IMO the case he describes is exactly the case we're talking about:
there is an address dependency between a write which stores the
address of an object and another thread which reads that stored
address and uses it to form a field reference.

And that's Sewell's own interpretation: I did ask this exact

> If that part of HS code is indeed about piggy-backing on address dependencies, and it is fine for AArch64,

Does what the code is about matter?  It's just a putfield.

> then it is as well fine for all other architectures (except Alpha)...

I think so, but I'm only sure about AArch64.

> I do think this is an over-cautious secondary release when publishing the reference to the field.

Indeed.  Please note that I have done a lot of jcstress testing; not
that that proves anything with respect to the abstract architecture,
of course.


More information about the hotspot-dev mailing list