RFR: Add support for CollectedHeap::get_safepoint_workers()
shade at redhat.com
Wed May 9 07:44:27 UTC 2018
On 05/09/2018 08:16 AM, Per Liden wrote:
> On 05/08/2018 05:49 PM, Aleksey Shipilev wrote:
>> On 05/08/2018 05:42 PM, Ramki Ramakrishna wrote:
>>> Hi Per,
>>> is there a bug id that you can link to the webrev for background (for those
>>> who came in late)?
>> This is the part of what we did in Shenandoah to exploit parallelism during safepoint cleanups:
>> You'll probably get better results if you can reuse GC worker threads to do the safepoint cleanups,
> I wonder if there would really be a measurable difference, but I could be wrong.
I remember from the times when Shenandoah had separate thread pools for concurrent and STW work that
handing over work to "cold" thread pool does confuse OS scheduler enough to be measurable on the
millisecond scale. So yeah, I would expect handing over SP work to hot GC workers that are already
balanced over the cores would be beneficial.
But that is a second-order concern. The first-order improvement is the actual parallelism in SP
cleanups, and for that even a separate thread pool is good to have.
More information about the zgc-dev