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

[David Holmes]

Hi Robbin,

Part 2:

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:

- src/hotspot/share/utilities/waitBarrier_generic.hpp

31 // Except for the barrier tag it self, it uses two counter to keep 
the semaphore
  32 // count correct and not leave any late thread hanging.

s/it self/itself/

s/counter/counters/

suggest s/hanging/waiting/

38   // Which means it can become a waiter.

suggest -> // These threads can become waiters.

---

-  src/hotspot/share/utilities/waitBarrier_generic.cpp

55   // We need an exact count and never go below 0.
56   // Otherwise the semaphore might contain to many posts.

suggest:

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

s/is/are/

More to follow.

Thanks,
David

On 24/11/2018 2:55 am, 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