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

[Per Liden]

On 6/23/20 12:29 PM, Stefan Karlsson wrote:
> 
> 
> On 2020-06-23 12:23, Kim Barrett wrote:
>>> 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.
> 
> Updated webrev:
>   https://cr.openjdk.java.net/~stefank/8247820/webrev.02.delta/
>   https://cr.openjdk.java.net/~stefank/8247820/webrev.02/

Looks good!

/Per

> 
>>
>> Gosh, I thought that was going to be much harder. I'm guessing Leo's
>> conversion of ParallelGC to use workgangs simplified things some.
> 
> :)
> 
> Thanks for reviewing,
> StefanK
> 
>>
>>