RFR: 8343704: Bad GC parallelism with processing Cleaner queues [v15]

Viktor Klang vklang at openjdk.org
Fri Nov 22 16:18:42 UTC 2024


On Thu, 21 Nov 2024 19:33:01 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 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Improve CleanerGC benchmark
>  - Check all elements are removable after random test
>  - Use RandomFactory in test
>  - Touchups
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Drop --add-exports from the test
>  - prev is not needed
>  - Do not need -ea -esa in tests, our testing infra adds them already
>  - Add the node cache
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/0b71f29b...507401c7

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 277:

> 275:          */
> 276:         public synchronized void insert(PhantomCleanable<?> phc) {
> 277:             if (head.size == NODE_CAPACITY) {

Given that `head.size` is a mutable member, it will be clearer to start out reading the current head.size into a local final variable and use that variable throughout the method where head.size is read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1854202122


More information about the core-libs-dev mailing list