RFR: 8261492: Shenandoah: reconsider forwardee accesses memory ordering

[Aleksey Shipilev]

Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.

For the forwardee update side, 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 forwardee updates, and "release" is enough.

For the forwardee load side, we need to guarantee "acquire". We do not do it now, reading the markword without memory semantics. It does not seem to pose a practical problem today, because GC does not access the object contents in the new copy, and mutators get this from the JRT-called stub that separates the fwdptr access and object contents access by a lot. It still should be cleaner to "acquire" the mark on load to avoid surprises.

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

# Baseline
[135.357s][info][gc,stats] Concurrent Evacuation          =   17.459 s (a =    66132 us) (n =   264) 
(lvls, us =      152,     2402,    74414,   123047,   142021)
[135.357s][info][gc,stats] Concurrent Update Refs         =   72.774 s (a =   276708 us) (n =   263) (
lvls, us =      354,     3281,   259766,   548828,   720417)

# Patched
[135.923s][info][gc,stats] Concurrent Evacuation          =   17.266 s (a =    61444 us) (n =   281)
(lvls, us =      137,     2754,    42773,   119141,   142979)
[135.923s][info][gc,stats] Concurrent Update Refs         =   74.234 s (a =   265121 us) (n =   280) 
(lvls, us =      354,     3672,   132812,   558594,   748677)

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:
 - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

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

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