RFR: 8152196: SuspendibleThreadSet::yield scales poorly
mikael.gerdin at oracle.com
Mon Mar 21 09:41:04 UTC 2016
On 2016-03-18 20:58, Kim Barrett wrote:
> Please review this fix for a performance scaling problem in
> SuspendibleThreadSet, leading to unnecessary additional safepoint
> latency as the number of suspendible threads increases. See the CR for
> details of the problem and some performance data.
I agree with your assessment in the bug that the limited set of
available synchronization primitives is unfortunate.
36 static Semaphore* _synchronize_wakeup = NULL;
Why not make it a static member in SuspendibleThreadSet?
Besides that, I think your change is good.
Since you've already performance tested your fix, I think it should be
pushed but here are some thoughts around another approach.
The primary reason for using semaphores for activating gc worker threads
was that Monitor::notify_all is inefficient for the purpose of simply
releasing threads without them requiring any mutual exclusion access
upon their activation.
Following that pattern the STS could have the joining or yielding
threads wait on a semaphore and use the Monitor to signal to the VM
thread requesting the synchronization. This would cause a situation
where the last STS thread would have to first notify the VM thread and
then wait on the semaphore but as long as the VM thread knows the exact
number to increment the semaphore by then that shouldn't be a problem.
I haven't really thought this approach through so there may be flaws in
it which makes it unfeasible.
> JPRT, RBT GC Nightly, local specjbb2015.
More information about the hotspot-gc-dev