RFR: 8343704: Bad GC parallelism with processing Cleaner queues [v9]
Chen Liang
liach at openjdk.org
Fri Nov 15 18:01:15 UTC 2024
On Fri, 15 Nov 2024 10:19:46 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:
>
> Do not need -ea -esa in tests, our testing infra adds them already
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 249:
> 247: * the time.
> 248: */
> 249: private Node cache;
Should the cache be soft, as it keeps the 4096-long array reachable? Not familiar with this matter, please enlighten me.
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 356:
> 354:
> 355: // Linked list structure.
> 356: Node prev;
The prev link seems only ever written but never read. This can be a singly-linked list, I believe.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844252581
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844256631
More information about the core-libs-dev
mailing list