[aarch64-port-dev ] RFR: aarch64: minor improvements of atomic operations

[Andrew Haley]

On 11/11/19 12:01 PM, Yangfei (Felix) wrote:

> I was also curious about the reason why full memory barrier is used
> here.  For add_and_fetch, I was thinking that there is no difference
> in functionality for the following two code snippet.  It's
> interesting to know that this may make a difference.  Can you
> elaborate more on that please?

For add_and_fetch the default atomic_memory_order is
memory_order_conservative. I'm not sure exactly what that means, but
it is stronger than SEQ_CST; it's been described as a "full barrier".

__ATOMIC_ACQ_REL for this operation translates approximately to

load
LoadLoad|LoadStore
add
StoreStore|LoadStore
store

In other words, there is nothing to prevent subsequent stores being
reordered with this store. Therefore your change does not meet the
specification for memory_order_conservative.

You could, if you wanted, only make this change for weaker memory
orderings, but AFAIK they are not used.

You could argue that AArch64 won't do such a reordering, but I'd reply
that even if AArch64 can't do such a reordering, GCC sure can.

And finally, is there any operation in HotSpot that actually requires
such strong memory semantics? Probably not, but no-one has ever been
brave enough to say so.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671