RFR: 8261493: Shenandoah: reconsider bitmap access memory ordering

[Aleksey Shipilev]

Shenandoah currently uses its own marking bitmap (added by JDK-8254315). It accesses the marking bitmap with "acquire" for reads and "conservative" for 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 marking bitmap updates, and "release" is enough.

I think both are actually excessive for marking bitmap accesses: we do not piggyback object updates on it, the atomics there are only to guarantee the access atomicity and CAS updates to bits. So we might as well use "relaxed" modes for both loads and updates.

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

# Baseline
[135.357s][info][gc,stats] Concurrent Marking             =   38.795 s (a =   146951 us) (n =   264)
    (lvls, us =      172,     1719,   150391,   275391,   348305)

# Patched
[130.475s][info][gc,stats] Concurrent Marking             =   34.874 s (a =   120672 us) (n =   289)
    (lvls, us =      178,     1777,   132812,   222656,   323957)

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:
 - 8261493: Shenandoah: reconsider bitmap access memory ordering

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

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