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

[Nick Gasson]

On 09/22/20 16:49 pm, Andrew Haley wrote:
>
> 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.

I see, thanks for the explanation. I've added the
is_c1_or_interpreter_only() check with a comment to explain why and
edited the documentation for cmpxchg_oop() a bit more. Hopefully the bot
will post the new webrev link...

--
Thanks,
Nick