RFR(m): 8214271: Fast primitive to wake many threads

Robbin Ehn robbin.ehn at oracle.com
Tue Dec 18 11:17:49 UTC 2018


Hi, here is a new version.

Inc:
http://cr.openjdk.java.net/~rehn/8214271/3/inc/webrev/

Full:
http://cr.openjdk.java.net/~rehn/8214271/3/full/webrev/

Thanks, Robbin

On 11/23/18 5:55 PM, Robbin Ehn wrote:
> Forgot RFR in subject.
> 
> /Robbin
> 
> 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, e.g.
>> 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).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rehn/8214271/webrev/
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8214271
>>
>> Passes 100 iterations of gtest on our platforms, both fastdebug and release.
>> And have been stable when used in safepoints (t1-8) (coming patches).
>>
>> Thanks, Robbin


More information about the hotspot-dev mailing list