RFR: Parallelize safepoint cleanup
Robbin Ehn
robbin.ehn at oracle.com
Tue May 30 12:57:23 UTC 2017
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
>
More information about the hotspot-gc-dev
mailing list