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

[Nick Gasson]

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'.

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

Commit messages:
 - 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

Changes: https://git.openjdk.java.net/jdk/pull/280/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=280&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252857
  Stats: 39 lines in 2 files changed: 5 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/280.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/280/head:pull/280

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