RFR: 8152196: SuspendibleThreadSet::yield scales poorly (original) (raw)

Mikael Gerdin mikael.gerdin at oracle.com
Mon Mar 21 09:41:04 UTC 2016

Hi Kim,

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.

CR: https://bugs.openjdk.java.net/browse/JDK-8152196 Webrev: http://cr.openjdk.java.net/~kbarrett/8152196/webrev.00/

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.

/Mikael

Testing: JPRT, RBT GC Nightly, local specjbb2015.

More information about the hotspot-gc-dev mailing list