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

[Dong Bo]

On Wed, 3 Mar 2021 12:45:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > 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].
>>> 
>>> I know that, but the Linux definition of a "full barrier" isn't quite as strong as HotSpot's `memory_order_conservative`, so we'd need a much more detailed analysis of what behaviours we can permit. Also, we'd have to find a strong reason to invest time in AArch64 without LSE instructions.
>>> 
>>> > BTW, the barrier-ordered-before applies with stlxr according to the architecture specification:
>>> 
>>> Sure, but so what? This is about the entire ldxr/stlxr combination and `memory_order_conservative` , in which we try to mimic Intel's "Loads and Stores Are Not Reordered with Locked Instructions" specification.
>> 
>> Hi,
>> 
>> For us, we still have servers used by our customers that does not support LSE extension.
>> 
>> Hm, from our point of view, `ldaxr+stlxr+dmb` and `ldxr+stlxr+dmb` provide the same order semantics.
>> The acquire are used to ensure all loads/stores that are after an `ldaxr` (actually loads/stores after the `dmb` of `atomic_*default*_impl` in this case) in program order, while the `dmb` has already guaranteed this for us.
>> Without the acquire, the loads/stores after the atomic operations still can not pass the `dmb`.
>> Remove the acquire does not change the order between preceding loads/stores and `stlxr`.
>
>> Without the acquire, the loads/stores after the atomic operations still can not pass the `dmb`.
>> Remove the acquire does not change the order between preceding loads/stores and `stlxr`.
> 
> Looks like it. I tried this example, which makes sure that a preceding store does not pass the load in LDXR;STLXR;DMB :
> 
>  MOConservative
> { 0:X0=a; 0:X1=b; 1:X0=a; 1:X1=b; a=0; b=0; }
> P0 | P1;
> MOV W3, #1 | MOV W3, #1;
> STLR W3, [X0] | STR W3, [X1];
> LDAR W1, [X1] | LDXR W1, [X0];
>               | STLXR W5, W4, [X0];
>               | CBZ W5, FOO;
>               | MOV W1, #99;
>               | FOO: ;
>               | DMB ISH;
> exists
> (0:X1=0 /\ 1:X1 = 0)
> 
> I don't think a preceding load can be reordered with the ```ldxr``` either, but I haven't written that test.

> > Without the acquire, the loads/stores after the atomic operations still can not pass the `dmb`.
> > Remove the acquire does not change the order between preceding loads/stores and `stlxr`.
> 
> Looks like it. I tried this example, which makes sure that a preceding store does not pass the load in LDXR;STLXR;DMB :
> 
> ```
> { 0:X0=a; 0:X1=b; 1:X0=a; 1:X1=b; a=0; b=0; }
> P0 | P1;
> MOV W3, #1 | MOV W3, #1;
> STLR W3, [X0] | STR W3, [X1];
> LDAR W1, [X1] | LDXR W1, [X0];
>               | STLXR W5, W4, [X0];
>               | CBZ W5, FOO;
>               | MOV W1, #99;
>               | FOO: ;
>               | DMB ISH;
> exists
> (0:X1=0 /\ 1:X1 = 0)
> ```
> 
> I don't think a preceding load can be reordered with the `ldxr` either, but I haven't written that test.

Hi, I tried the example below to verify the order of preceding load as mentioned:
AArch64 ExclusiveRead
{ 0:X8=a; 0:X9=b; 1:X8=a; 1:X9=b; a=1; b=1; }
P0            | P1                 ;
MOV W3, #3    | LDR W3, [X9]       ;
MOV W4, #5    | LDXR W1, [X8]      ;
STR W3, [X8]  | STLXR W5, W4, [X8] ;
STLR W4, [X9] | CBZ W5, FOO        ;
              | MOV W1, #99        ;
              | FOO:               ;
              | DMB ISH            ;
exists
(1:X1=1 /\ 1:X3=5)
No `1:X1=1 /\ 1:X3=5` witnessed.

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

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