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

[Nick Gasson]

On Mon, 21 Sep 2020 09:04:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> C1 atomic operations are supposed to be sequentially consistent by
> default but the variant in the Shenandoah C1 barrier set assembler only
> provides a half-barrier when the CAS succeeds. Added a trailing full
> barrier and load-acquire to exactly match the non-Shenandoah C1 CAS
> implementation. This prevents any memory accesses following the CAS
> operation being observed before it.
> 
> Also adjusted the documentation for ShenandoahBarrierSetAssembler
> ::cmpxchg_oop as it currently claims to be sequentially consistent by
> default but it's not clear what the "default" values of acquire and
> release should be, and the comment for acquire/release implies to me
> that setting them to true would relax the ordering guarantees but
> actually it's the opposite. I tried to simplify this and make it less
> ambiguous.
> 
> One other thing I noticed when reading this: the comment
> 
>    // Step 4. CAS has failed because the value most recently fetched
>    // from addr (which is now held in tmp1) ...
> 
> is wrong on non-LSE systems because tmp1 is rscratch1 and that is
> clobbered by the call to __ cmpxchg() at the end of step3. Although it
> doesn't matter because the value in tmp1 is not used after that point.
> Adjusted the comment to clarify this.
> 
> Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs
> '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'.

This pull request has now been integrated.

Changeset: 8e87d46f
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e87d46f
Stats:     51 lines in 2 files changed: 9 ins; 30 del; 12 mod

8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

Reviewed-by: rkennke, shade

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

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