RFR: 8277757: Parallelize humongous reclaim

Thomas Schatzl tschatzl at openjdk.java.net
Tue Nov 30 12:51:10 UTC 2021

On Tue, 30 Nov 2021 12:06:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use parallel threads for humongous reclaim.
> **Summary**
> The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 
> **Testing**
> - [x] Mach5 tier 1-3
> - [x] Local testing verifying JFR tests are unaffected
> - [x] Performance testing checking for regressions

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 290:

> 288:   }
> 289: 
> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }

Would it be possible to pack `_humongous_reclaim_candidates` into `should_execute()`? Without candidates, there should be no need to even try this phase. There needs to be some adjustment with the log messages though.

Then `worker_cost` also does not need the `MAX2` then.

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 292:

> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
> 291: 
> 292:   double worker_cost() const override { return MAX2(1u, _humongous_reclaim_candidates); }

I think equating the number of threads with the number of reclaim candidates is too big a number; there is relatively little work to do per region; I would probably use some (magic) divisor based on the number of regions to look through instead, but I guess you measured that; then again, other parts of `Post Evacuate Cleanup 2` effectively already always spawn the maximum number of threads anyway?


PR: https://git.openjdk.java.net/jdk/pull/6612

More information about the hotspot-gc-dev mailing list