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

David Holmes david.holmes at oracle.com
Wed Nov 28 05:41:15 UTC 2018

Hi Robbin,

Part 3 (and final part)

This is looking at the futex implementation and the test.

Overall looks good!

Shouldn't you be using the FUTEX_*_PRIVATE variants as this is a 
process-local FUTEX?

Your main code would be simpler to read (and thus understand) if your 
futex helper function handled the unused arguments e.g. instead of:

static int futex(volatile int *uaddr, int futex_op, int val,
                  const struct timespec *timeout, int *uaddr2, int val3)
    return syscall(SYS_futex, uaddr, futex_op, val, timeout, uaddr2, val3);

use (with name changes):

static int futex(volatile int *addr, int futex_op, int op_arg) {
    return syscall(SYS_futex, addr, futex_op, op_arg, NULL, NULL, 0);


Minor suggestions on this comment block:

   88     // Return value 0, re-check in case of spurious wake-up.
   89     // EINTR and re-check and go back to waiting.
   90     // EAGAIN we already are disarmed, we should pass the check,
   91     // if not re-armed with same tag.


   // Return value 0: woken up, but re-check in case of spurious wakeup
   // Error EINTR: woken by signal, so re-check and re-wait if necessary.
   // Error EAGAIN: we are already disarmed and so will pass the check

As per initial review comments I think re-arming with same tag should be 
an error. I think the tag semantics should be that the tag is a strictly 
increasing value, and we can then store the previous tag and check that.


The test could do with at least an introductory comment block explaining 
the basic operation of the test. Further inline comments wouldn't hurt 


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

More information about the hotspot-dev mailing list