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

Andrew Haley aph at redhat.com
Mon Nov 11 15:05:10 UTC 2019

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


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>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-dev mailing list