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

[David Holmes]

Hi Robbin,

Looks good, small doc follow up below ...

On 18/12/2018 9:17 pm, Robbin Ehn wrote:
> Hi, here is a new version.
> 
> Inc:
> http://cr.openjdk.java.net/~rehn/8214271/3/inc/webrev/

src/hotspot/share/utilities/waitBarrier.hpp

I like the idea of there being an "owner" thread but it needs to be 
documented. Suggest:

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

Sound reasonable?

Otherwise this all looks good!

Thanks,
David
-----


> 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