RFR: 8343704: Bad GC parallelism with processing Cleaner queues [v14]
Brent Christian
bchristi at openjdk.org
Thu Nov 21 05:58:22 UTC 2024
On Wed, 20 Nov 2024 09:19:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>>
>> I'll put performance data in a separate comment.
>>
>> Additional testing:
>> - [x] Original reproducer improves drastically
>> - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>> - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>> - [x] `java/lang/ref` tests in release
>> - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Check all elements are removable after random test
test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 45:
> 43:
> 44: // Deliberately a linked list to avoid exposing external parallelism to GC.
> 45: Target prev;
Is `CleanerGC.prev` used?
test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 57:
> 55: @Benchmark
> 56: public void test() {
> 57: System.gc();
How confident are we that most/all/(any?) `Target` objects are being collected?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851391803
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851402011
More information about the core-libs-dev
mailing list