RFR: Parallelize safepoint cleanup

Roman Kennke rkennke at redhat.com
Tue May 30 13:09:28 UTC 2017


Hi Robbin,

I'm currently testing  an abstraction that allows to use GC workers, and also makes serial and parallel cleanup to use the same code path. Stay tuned ;-)

/Roman

Am 30. Mai 2017 14:57:23 MESZ schrieb Robbin Ehn <robbin.ehn at oracle.com>:
>Hi Roman,
>
>On 05/29/2017 04:16 PM, Roman Kennke wrote:
>> 
>> I agree that having a single pool would be good. The current WorkGang
>> doesn't do it though, because we can't borrow threads while the GC is
>> doing work, at least not in a way that is GC agnostic (see my reply
>to
>> Robbin).
>
>Correct me if I'm wrong, using WorkGang works for all the GCs that we
>have in JDK10.
>(serial I would assume just use the VmThread)
>
>If Shenandoah needs modification to the WorkGang then you would be-able
>to have them in your repo.
>If the modification is very large alternative you could use separate
>thread pool for this in your Shenandoah repo.
>Since for vanilla JDK 10, as now, I don't see we need it?
>
>> 
>> Yeah, I will think about it. The easiest way out would be to treat
>the
>> serial case as 1-thread-MT case (called by VMThread), but this also
>> means we can't easily keep the existing code path as-is while having
>a
>> new separate code path. Maybe give the new code path some testing and
>> time to iron out bugs (if any) and later switch the old path to a
>> degenerated 1-threaded-MT path?
>
>This sounds good, I think you could get away with doing just 1 case and
>we will iron out bugs faster I guess.
>
>Thanks Robbin
>
>> 
>> Roman
>> 

-- 
Sent from my FairPhone



More information about the hotspot-gc-dev mailing list