RFR: 8277757: Parallelize humongous reclaim

[Stefan Johansson]

On Tue, 30 Nov 2021 14:12:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

That's a fair point. We should avoid adding more "bad" estimates. 

>From my tests it looks like the cost is both depending on the number of humongous objects reclaimed and the number of regions reclaimed. Reclaiming 600 regions used by 1 objects is cheaper than reclaiming 600 objects using 1 region (using a single worker). So a good estimate should take both the number of objects and the number of regions into consideration. And somehow scale it down by some "magic number" similar to what is done for some other tasks. 

I'll take another look at this.

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

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