RFR: 8247820: ParallelGC: Process strong OopStorage entries in parallel

[Kim Barrett]

> On Jun 23, 2020, at 4:23 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this patch to both unify handling of all OopStorage instances and parallelize it in the root processing of the Parallel GC.
> 
> https://cr.openjdk.java.net/~stefank/8247820/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8247820
> 
> This removes the explicit enumeration of "strong" OopStorages in the Parallel GC. This is a step towards allowing the Runtime code to add new OopStorages without having to update all GCs.
> 
> It also parallelizes the processing of the OopStorages, using the class that's being introduced in:
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-June/030152.html
> 
> Tested with tier1-3
> 
> Thanks,
> StefanK

------------------------------------------------------------------------------
src/hotspot/share/gc/parallel/psScavenge.cpp
 367     // Scavenge OopStorages
...
 376     PSThreadRootsTaskClosure closure(worker_id);
 377     Threads::possibly_parallel_threads_do(true /*parallel */, &closure);

I think it's better to do these in the other order.  Processing the
OopStorages is very parallel, with relatively small work chunks.
Thread processing could encounter a large thread late in the process,
leaving the one thread processing it as the long pole, with other
threads possibly not having much to do, other than (relatively
expensive) stealing.

Similarly for psParallelCompact.

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

Other than that one comment, looks good.

Gosh, I thought that was going to be much harder. I'm guessing Leo's
conversion of ParallelGC to use workgangs simplified things some.