RFR: 8261495: Shenandoah: reconsider update references memory ordering [v2]
Aleksey Shipilev
shade at openjdk.java.net
Wed Feb 10 19:07:37 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 "acq_rel" 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.
>
> 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
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Do acq_rel instead
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/2498/files
- new: https://git.openjdk.java.net/jdk/pull/2498/files/d83b9af4..87a609f4
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2498&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2498&range=00-01
Stats: 41 lines in 1 file changed: 38 ins; 0 del; 3 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