RFR: 8152196: SuspendibleThreadSet::yield scales poorly

[Mikael Gerdin]

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.
>
>