RFR: 8262519: AArch64: Unnecessary acquire semantics of memory-order-conservative atomics in C++ Hotspot code

[Dong Bo]

On Tue, 2 Mar 2021 12:30:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Without the acquire, `1:X0=1 /\ 1:X2=0` exists, then we do have a problem.
>> But for `memory_order_conservative`, I guess there should be a trailing DMB right after the CASAL under current `gen_cas_entry` code:
>>     __ lse_cas(prev, exchange_val, ptr, size, acquire, release, /*not_pair*/true);
>>     if (order == memory_order_conservative) {
>>       __ membar(Assembler::StoreStore|Assembler::StoreLoad);
>>     }
>> That is:
>> AArch64 exper
>> { 0:X1=x; 0:X3=y; 1:X1=y; 1:X3=x; 1:X4=z; }
>> P0           | P1               ;
>> MOV W0,#1    | LDR W0,[X1]      ;
>> STR W0,[X1]  | CASAL W5,W6,[X4] ;
>> MOV W2,#1    | DMB ISH          ;
>> STLR W2,[X3] | LDR W2,[X3]      ;
>> exists
>>  (1:X0=1 /\ 1:X2=0)
>> With the DMB, herd7 produces same results with or without acquire.
>> 
>> Thanks.
>
> I don't want to see this go in, for two reasons. Firstly, barrier-ordered-before only applies to atomic instructions with both acquire *and* release semantics, as the comment says. So we cannot rely on that guarantee, and we'd need some much more detailed analysis to make this changes. Secondly, the architecture specification is being revised, and the result will hopefully be that we can get a better version than this. So please, leave this alone for now.

OKAY, this make sense to us.

If it is OK to keep the exclusive part of this patch? :-)
As far as we know, the exclusive instructions are not being revised.
And we see `ldxr+stxlr+dmb` have been used in linux kernel since 2014 [1], and still used by now [2].

[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1391516953-14541-1-git-send-email-will.deacon@arm.com/
[2] https://github.com/torvalds/linux/blob/7a7fd0de4a9804299793e564a555a49c1fc924cb/arch/arm64/include/asm/atomic_ll_sc.h#L102

-------------

PR: https://git.openjdk.java.net/jdk/pull/2788