Release store in C2 putfield

[David Holmes]

Ignore this.

Was trying to do too many things at once and missed the whole point.

Sorry.

David

On 4/09/2014 12:08 PM, David Holmes wrote:
> 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.
>>