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

[Robbin Ehn]

Thanks, fixed.

I'll send update once I sorted out part 3.

On 11/28/18 5:17 AM, David Holmes wrote:
> 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).

I think once of the best features is if the VM thread gets swapped out there is 
a big chance that other threads keep posting. An alternative option is to create 
a new Semaphore for each arm and thus allow extra posts.

/Robbin

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