RFR: 8261495: Shenandoah: reconsider update references memory ordering [v4]
shade at openjdk.java.net
Tue Jun 22 17:58:33 UTC 2021
On Tue, 16 Feb 2021 13:21:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> - Comment touchup
> - Specialize out witness-checking methods, drop acquire again
> - Even more explanation
> - Move the comment
> - Also handle clearing the oops
> - Minor touchups to the comment
> - Merge branch 'master' into JDK-8261495-shenandoah-updaterefs-memord
> - Use release only
> - Do acq_rel instead
> - 8261495: Shenandoah: reconsider update references memory ordering
Not now, bot. Still waiting.
More information about the hotspot-gc-dev