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

[Yangfei (Felix)]

> On 11/11/19 3:05 PM, Andrew Haley wrote:
> > 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.
> 
> Here's a place where it really does matter.
> 
> void ShenandoahPacer::restart_with(size_t non_taxable_bytes, double
> tax_rate) {
>   size_t initial = (size_t)(non_taxable_bytes * tax_rate) >> LogHeapWordSize;
>   STATIC_ASSERT(sizeof(size_t) <= sizeof(intptr_t));
>   Atomic::xchg((intptr_t)initial, &_budget);
>   Atomic::store(tax_rate, &_tax_rate);
>   Atomic::inc(&_epoch);
> 
> Note: the xchg is conservative, the store is plain. The xchg value should be
> visible before the store.

Thanks for explaining this.  I see your point now.  
For memory_order_conservative order, looks like that ppc enforced an order which is stronger than aarch64.  
ppc issues two full memory barriers: one before the loop and one after the loop.  
But for aarch64, the preceding load/store can still floating after the first ldxr instruction :  

.L2:
        ldxr    x2, [x1]
        add     x2, x2, x0
        stlxr   w3, x2, [x1]
        cbnz    w3, .L2
        dmb     ish

So my question is: for "two-way memory barrier", do we need another full barrier before the loop?  

Felix