RFR: 8277757: Parallelize humongous reclaim

[Thomas Schatzl]

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

>> 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.

I still prefer to scale the number of threads to the (largest) actual work, which is as we seem to agree on actually iterating through the regions, for that particular phase rather than relying on other phases getting things right or this phase "helping" other phases - or at least try to. Otherwise we could probably just always use a maximum amount of threads available in the hope that they'll help out.

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

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