RFR: 8261495: Shenandoah: reconsider update references memory ordering

[Aleksey Shipilev]

Shenandoah update heap references code uses default Atomic::cmpxchg to avoid races with mutator updates. Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64.

This seems to be excessive for Shenandoah update references code, and "relaxed" is enough. We do not seem to piggyback on update-references memory effects anywhere (in fact, if not for mutator, we would not even need a CAS).

Sample run with aggressive (back-to-back cycles) on SPECjvm2008:compiler.compiler on AArch64:

# Baseline
[135.065s][info][gc,stats] Concurrent Update Refs         =   73.685 s (a =   295924 us) (n =   249) 
    (lvls, us =      354,     3418,   349609,   564453,   715405)

# Patched
[127.649s][info][gc,stats] Concurrent Update Refs         =   54.389 s (a =   169437 us) (n =   321)
    (lvls, us =      324,     2188,   183594,   322266,   394495)

Average time goes down, the number of GC cycles go up, since the cycles are shorter.

Additional testing:
 - [x] Linux x86_64 hotspot_gc_shenandoah
 - [x] Linux AArch64 hotspot_gc_shenandoah
 - [x] Linux AArch64 tier1 with Shenandoah

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

Commit messages:
 - 8261495: Shenandoah: reconsider update references memory ordering

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

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