Release store in C2 putfield

[David Holmes]

On 4/09/2014 3:00 AM, Andrew Haley wrote:
> On 09/03/2014 05:49 PM, Aleksey Shipilev wrote:
>> Hi Andrew,
>>
>> On 09/03/2014 06:16 PM, Andrew Haley wrote:
>>> In Parse::do_put_xxx, I see
>>>
>>> const MemNode::MemOrd mo = is_vol ? // Volatile fields need releasing stores. MemNode::release : // Non-volatile fields also need releasing stores if they hold an // object reference, because the object reference might point to // a freshly created object. StoreNode::release_if_reference(bt);
>>>
>>> AArch64 doesn't need a release store here: its memory guarantees are strong enough that a simple store is sufficient.  But my question is not about that, but how to handle it properly.
>>
>> I can't answer the question you posed, but let me challenge your premise.
>>
>> 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
> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf 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.

I don't see how that applies to general volatile putfields??

The reason the PPC64 port added the additional MemNodes was so that some 
of the special cases could be handled via those nodes to avoid redundant 
barriers.

David
------






> Andrew.
>