[aarch64-port-dev ] barrier issue in cmpxchgptr implementation

[Andrew Haley]

Hi,

On 06/30/2015 03:34 PM, Tangwei (Euler) wrote:

>   I checked the MacroAssembler::cmpxchgptr implementation in JVM,
> and found load-aquire/store-release followed by a full memory
> barrier used to simulate the behavior of X86 cmpxchg.

Well, it's not necessarily doing that.  It is a cmpxchg which needs to
be strong enough for HotSpot's usage: it does not necessarily have to
be as strong as x86.  But let's move on...

> Following is the code snapshot from the function for your
> reference. In my opinion, the cmpxchg must provide full
> bi-directional fence semantics. Is there anyone can help to explain
> why one membar in the end is enough for cmpxchg? Or one more memory
> barrier commented out is needed to add at the beginning?

>   // membar(AnyAny)  // is this needed?
> retry_load:

LoadLoad|LoadStore

> ldaxr(tmp, addr);
>   cmp(tmp, oldv);
>   br(Assembler::NE, nope);

StoreStore|LoadStore

>   stlxr(tmp, newv, addr);
>   cbzw(tmp, succeed);
>   b(retry_load);
> nope:
>   membar(AnyAny);

AnyAny.  Nothing can pass here.

Please explain what problem you see with this sequence.  We need an
example of incorrect operation.

> But after checked intrinsic in GCC with following simple case, I
> found there is no barrier around load-acquire/store-release.  I am a
> little confused now. Which instruction sequence should be chosen to
> simulate X86 cmpxchg?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

As I said, that depends if you really need to simulate X86 cmpxchg.

Andrew.