RFR: Parallelize safepoint cleanup

Roman Kennke rkennke at redhat.com
Mon May 29 14:08:27 UTC 2017


Am 29.05.2017 um 15:39 schrieb Erik Österlund:
> Hi,
>
> How do we feel about reusing the Parallel GC Threads work gang during
> safepoint cleanup?
I actually tried that, but failed, at least with Shenandoah, because...

> We know that the Parallel GC Threads worker gang is idle then.

Not Shenandoah :-) Shenandoah GC threads are currently happy to continue
working during (non-GC) safepoints. One exception is the heap dumper,
which currently requires some extra synchronization. If you know of any
other safepoints that would require stopping concurrent GC threads
(marking, evacuating or updating references) let me know. I haven't
found any. Parallelizing safepoint cleanup might be a reason to
implement GC thread safepointing though.

Another problem with this approach is that it's clearly GC dependend,
and requires support (i.e. a worker thread pool) and coordination (i.e.
pause-resume GC work) by the GC. For example, as Kirk pointed out,
serial gc couldn't support that.

> This saves creating another gazillion threads and another JVM flag to
> keep track of.

It would only be a few threads. There's just not that much work to do.
The prime scenario for this seems to be many- (like hundreds or
thousands of) threads work loads, in which case it hardly matters to add
some more to support more efficient cleanup.

Roman



More information about the hotspot-runtime-dev mailing list