RFR(m): 8214271: Fast primitive to wake many threads
david.holmes at oracle.com
Thu Dec 20 06:08:53 UTC 2018
Looks good, small doc follow up below ...
On 18/12/2018 9:17 pm, Robbin Ehn wrote:
> Hi, here is a new version.
I like the idea of there being an "owner" thread but it needs to be
// An armed WaitBarrier prevents threads from advancing until the
// barrier is disarmed and the waiting threads woken. The barrier is
// armed by setting a non-zero value - the tag.
+ // When the WaitBarrier is created, a thread is designated the owner
+ // and is the thread that should arm/disarm/wake the WaitBarrier. In
+ // debug builds this is enforced.
// Expected Usage:
! // - Arming/owning thread:
I would also like to see a small section on usage errors:
// It is a usage error to:
// - call wake on a barrier that is still armed
// - call arm on a barrier that is already armed
// - call disarm on a barrier that is not armed
// - arm with the same tag as last used
// Usage errors are checked in debug builds but may be ignored otherwise.
Otherwise this all looks good!
> Thanks, Robbin
> On 11/23/18 5:55 PM, 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
>>> 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