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

[Yangfei (Felix)]

> -----Original Message-----
> From: Yangfei (Felix)
> Sent: Tuesday, November 12, 2019 10:58 AM
> To: 'Andrew Haley' <aph at redhat.com>; aarch64-port-dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: [aarch64-port-dev ] RFR: aarch64: minor improvements of atomic
> operations
> 
> > 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?

This has been discussed somewhere before: https://patchwork.kernel.org/patch/3575821/ 
Let's keep the current status for safe.  

Felix