RFR: 8261500: Shenandoah: reconsider region live data memory ordering

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8261500: Shenandoah: reconsider region live data memory ordering

Aleksey Shipilev-5
Current Shenandoah region live data tracking uses default CAS updates to achieve atomicity of 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 live data tracking, and "relaxed" could be used instead. The only serious user of that data is collection set chooser, which runs at safepoint and so everything should be quiescent when that happens.

Additional testing:
 - [x] Linux x86_64 hotspot_gc_shenandoah
 - [x] Linux AArch64 hotspot_gc_shenandoah
 - [x] Linux AArch64 tier1 with Shenandoah

-------------

Commit messages:
 - 8261500: Shenandoah: reconsider region live data memory ordering

Changes: https://git.openjdk.java.net/jdk/pull/2503/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2503&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261500
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2503.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2503/head:pull/2503

PR: https://git.openjdk.java.net/jdk/pull/2503
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261500: Shenandoah: reconsider region live data memory ordering

Zhengyu Gu-3
On Wed, 10 Feb 2021 10:40:26 GMT, Aleksey Shipilev <[hidden email]> wrote:

> Current Shenandoah region live data tracking uses default CAS updates to achieve atomicity of 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 live data tracking, and "relaxed" could be used instead. The only serious user of that data is collection set chooser, which runs at safepoint and so everything should be quiescent when that happens.
>
> Additional testing:
>  - [x] Linux x86_64 hotspot_gc_shenandoah
>  - [x] Linux AArch64 hotspot_gc_shenandoah
>  - [x] Linux AArch64 tier1 with Shenandoah

Looks good

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2503
Reply | Threaded
Open this post in threaded view
|

Integrated: 8261500: Shenandoah: reconsider region live data memory ordering

Aleksey Shipilev-5
In reply to this post by Aleksey Shipilev-5
On Wed, 10 Feb 2021 10:40:26 GMT, Aleksey Shipilev <[hidden email]> wrote:

> Current Shenandoah region live data tracking uses default CAS updates to achieve atomicity of 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 live data tracking, and "relaxed" could be used instead. The only serious user of that data is collection set chooser, which runs at safepoint and so everything should be quiescent when that happens.
>
> Additional testing:
>  - [x] Linux x86_64 hotspot_gc_shenandoah
>  - [x] Linux AArch64 hotspot_gc_shenandoah
>  - [x] Linux AArch64 tier1 with Shenandoah

This pull request has now been integrated.

Changeset: c6eedda8
Author:    Aleksey Shipilev <[hidden email]>
URL:       https://git.openjdk.java.net/jdk/commit/c6eedda8
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8261500: Shenandoah: reconsider region live data memory ordering

Reviewed-by: zgu

-------------

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