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

Kim Barrett kim.barrett at oracle.com
Tue Jun 23 10:23:07 UTC 2020


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




More information about the hotspot-gc-dev mailing list