RFR: 8277757: Parallelize humongous reclaim

[Stefan Johansson]

On Tue, 30 Nov 2021 12:47:35 GMT, Thomas Schatzl <tschatzl 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
>
> 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?

Again, I have had thoughts along the same lines :) But since we, as you say, already spawn the max number of threads, letting them all help out seems ok. 

At least the number of candidates is always lower or equal to the number of regions being taken care of.

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

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