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

[Laurent Bourgès]

On Mon, 25 Nov 2024 08:32:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> How about this:
>> 
>>> ...the problem is in GC time hiccups to walk the large linked lists.
>> 
>> Though, for this test, `CleanableList` itself is not being walked.
>> 
>> Rather, `CleanableList` itself is a factor in as much as it exists on the heap, populated with `PhantomCleanableRef`s.
>> 
>> So this test measures what effect, if any, the conversion from the old linked list to new CleanableList has on GC, when referents are _not_ becoming unreachable.
>
>> Though, for this test, CleanableList itself is not being walked.
> 
> I think this is a matter of definition of "CleanableList itself is not being walked". 
> 
> The Java code does not walk the list in this test, but GC does the walk the list as part of GC cycle. This is what this test sets up: it builds the large list of cleanable objects, makes sure the cleanable objects are reachable, so associated cleaners stay in the list, and then forces GC to mark the entire heap. When there is a large linked list formed by old `ClenableList` implementation, GC times suffer, because GC cannot parallelize marking work. This is why this benchmark improves with new implementation: GC becomes more parallel/efficient.
> 
>> So this test measures what effect, if any, the conversion from the old linked list to new CleanableList has on GC, when referents are not becoming unreachable.
> 
> Yes. And "if any" in this test shows up as 2..3x improvement in GC times :)

Congratulations !

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

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