RFR: 8261492: Shenandoah: reconsider forwardee accesses memory ordering [v10]

[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.
> 
> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
> 
> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
> 
> Before:
> 
> 
> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
> 
> 
> After:
> 
> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 `tier1` with Shenandoah
>  - [x] Linux AArch64 `tier1` with Shenandoah

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - Doing acquires on most paths, and relaxed on the path that matters: heap update
 - Even more discussion
 - Additional discussion and corner cases
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - Add TODO
 - "acquire" is too slow on aarch64, and does not seem neccessary anyway
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - 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=09
  Stats: 174 lines in 13 files changed: 104 ins; 30 del; 40 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