RFR(m): 8214271: Fast primitive to wake many threads
david.holmes at oracle.com
Wed Nov 28 04:17:15 UTC 2018
I've looked at the generic waitBarrier implementation and it seems okay.
A lot of the usage constraints not clear in the API are more evident in
the asserts in the code. I still have some doubts about the benefit of
helping with the wakeups rather than it all being done by one thread,
due to potential contention on the semaphore - but your performance
numbers show it can help (I just hope it doesn't hurt on other
platforms/systems - time will tell).
Some minor nits with comments:
31 // Except for the barrier tag it self, it uses two counter to keep
32 // count correct and not leave any late thread hanging.
38 // Which means it can become a waiter.
suggest -> // These threads can become waiters.
55 // We need an exact count and never go below 0.
56 // Otherwise the semaphore might contain to many posts.
// We need an exact count which never goes below zero,
// otherwise the semaphore may be signalled too many times.
74 // We must loop here until there is no waiters or potential waiters.
More to follow.
On 24/11/2018 2:55 am, Robbin Ehn wrote:
> Forgot RFR in subject.
> On 2018-11-23 17:51, Robbin Ehn wrote:
>> Hi all, please review.
>> When a safepoint is ended we need a way to get back to 100%
>> utilization as fast
>> as possible. 100% utilization means no idle cpu in the system if there
>> is a
>> JavaThread that could be executed. The traditional ways to wake many,
>> semaphore, pthread_cond, is not implemented with a single syscall
>> instead they
>> typical do one syscall per thread to wake.
>> This change-set contains that primitive, the WaitBarrier, and a gtest
>> for it.
>> No actual users, which is in coming patches.
>> The WaitBarrier solves by doing a cooperative semaphore posting,
>> threads woken
>> will also post. On Linux we can instead directly use a futex and with one
>> syscall wake all. Depending on how many threads and cpus the
>> performance vary,
>> but a good utilization of the machine, just on the edge of saturated,
>> the time to reach 100% utilization is around 3 times faster with the
>> WaitBarrier (where futex is faster than semaphore).
>> Passes 100 iterations of gtest on our platforms, both fastdebug and
>> And have been stable when used in safepoints (t1-8) (coming patches).
>> Thanks, Robbin
More information about the hotspot-dev