RFR(m): 8214271: Fast primitive to wake many threads
robbin.ehn at oracle.com
Mon Dec 17 11:08:19 UTC 2018
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.
> 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/
> 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.
> // 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.
> More to follow.
> On 24/11/2018 2:55 am, 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, 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).
>>> 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