RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

[Andrew Haley]

On 22/09/2020 02:47, Nick Gasson wrote:
> On 09/21/20 18:23 pm, Andrew Haley wrote:
>>
>> We only need the trailing membar if is_c1_or_interpreter_only(). Otherwise
>> all volatile loads in C1 are preceded by a leading membar() so we don't
>> need a trailing one as well.
>
> Yes, OK. But the same applies to LIR_Assembler::casw() and casl().
> Should I change those as well? I don't see any reason for them to be
> different.

Neither do I, but I'd rather you didn't touch anything that wasn't
broken.

The history is a little untidy: to begin with I thought we'd be able
to use ldar/stlr instructions as intended by Arm to provide a
fully-sequentially- consistent set of operations, but it became clear
that assumptions about memory fences were so baked into C1 that it'd
be too disruptive to fix.

[ Originally cas used ldaxr;stlxr. On Feb 14 2014 I changed it to be
membar;ldxr;stxr;membar. On April 1 (!) 2014 to ldaxr;stxr;membar. On
Apr 10 2014 to ldaxr;stlxr;membar. This was a the result of much
toing-and-froing with various people, including Arm. ]

Given that we now have a membar in C1 before a volatile load when
needed for compatibility with C2, I don't believe we also need the
trailing membars after volatile stores.

However, I also don't believe that removing them is worth the effort
and risk. But that isn't the same as saying we should start *adding*
unnecessary membars now. C1 performance isn't critical, but stability
is.

>>>> 462 // By default, this operation has relaxed memory ordering
>>
>> No, it has whatever memory ordering you tell it. Plus, if you pass
>> both acquire and release, sequential consistency.
>
> If volatile load is implemented as "ldr ; dmb ishld" then this function
> alone doesn't provide sequential consistency even with acquire and
> release both set. That's why the original comment is misleading.

I see.

> Can you suggest an alternate wording here? Perhaps we can delete all
> mention of memory ordering and leave it up to the reader.

Perhaps so.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671