RFR: 8261495: Shenandoah: reconsider update references memory ordering [v6]

Aleksey Shipilev shade at openjdk.java.net
Wed Jun 23 16:34:44 UTC 2021

> 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 "release" 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). But, there is an interplay with concurrent evacuation and updates from self-healing.
> 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

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

  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=05
  Stats: 130 lines in 7 files changed: 93 ins; 15 del; 22 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

More information about the hotspot-gc-dev mailing list