RFR: 8363932: G1: Better distribute KlassCleaningTask

Albert Mingkun Yang ayang at openjdk.org
Mon Sep 22 08:07:19 UTC 2025


On Tue, 16 Sep 2025 15:54:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to parallel klass cleaning to improve performance.
> 
> The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads.
> 
> Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads).
> 
> The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass.
> 
> E.g.
> 
> CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4;
> vertical links are subklass references, while horizontal links are sibling references.
> 
> j.l.O
>   |
>   A - B - c - 3
>   |
>   0 - 2 - C - 1
> 
> 
> CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead).
> 
> So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`.
> Thread 2 will only remove the link to `3` of `c`.
> 
> The result is
> 
> j.l.O
>   |
>   A - B - c
>   |
>   C
> 
> 
> There should be no unnecessary object graph walking.
> 
> There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print
> 
> 
> unlinking class (subclass): 0
> unlinking class (subclass): 2
> 
> 
> With the change, to avoid following the subklasses of the graph twice, it prints
> 
> 
> unlinking class (subclass): 0
> unlinking class (sibling): 0
> 
> 
> because the string in brackets is the actual link that is followed. I can revert that change.
> 
> With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Preexisting: These two methods, `subklass` and `next_sibling`, sounds like plain getters, but they actually query liveness and skip dead klasses. I wonder whether it's possible to prune dead klasses in one go at some place and turn these two methods into plain getters.

src/hotspot/share/gc/shared/parallelCleaning.hpp line 57:

> 55: // Cleans out the Klass tree from stale data.
> 56: class KlassCleaningTask : public StackObj {
> 57:   ClassLoaderDataGraphIteratorAtomic _cld_iterator;

I suggest adding `_atomic` suffix to the field name.

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

PR Review: https://git.openjdk.org/jdk/pull/27316#pullrequestreview-3250946195
PR Review Comment: https://git.openjdk.org/jdk/pull/27316#discussion_r2366965395


More information about the hotspot-gc-dev mailing list