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

[Andrew Haley]

On Tue, 2 Mar 2021 12:21:53 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> No. Try this with and without the acquire:
>> 
>>  Jon1
>> { 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 | LDR W2,[X3];
>>  STLR W2,[X3] | ;
>> exists
>> (1:X0=1 /\ 1:X2=0)```
>
> 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.

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

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