Release store in C2 putfield
david.holmes at oracle.com
Thu Sep 4 02:20:50 UTC 2014
Was trying to do too many things at once and missed the whole point.
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.
>>>> 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
>>> 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
More information about the hotspot-dev