On park and unpark

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

On park and unpark

Andrew Haley
At the bottom of every blocking operation in j.u.c is the park/unpark
pair.  I'm curious about the choice of these primitives.  Herlihy et
al [1] use a mutex/condvar when they want to block (as indeed does
HotSpot's implementation of park/unpark) and I haven't been able to
find park and unpark in high-level lanuguages apart from Java.

To my questions: why use park/unpark in j.u.c?  And where does the
original idea come from anyway?  I see that BSD and Solaris have the
lwp_park syscall so perhaps Java's park/unpark was based on that, but
we don't use lwp_park in HotSpot, even for Solaris.

Maybe park/unpark were actually invented someone at by BSD, but Forth
has used a very similar primitive (STOP and awaken) since the 1970s.
Perhaps the idea is "just obvious" and has been reinvented several
times.

[1] The Art of Multiprocessor Programming, Maurice Herlihy, Nir
Shavit, Morgan Kaufmann, 2011

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Doug Lea
On 08/25/2017 05:37 AM, Andrew Haley wrote:
> At the bottom of every blocking operation in j.u.c is the park/unpark
> pair.  I'm curious about the choice of these primitives.

They were introduced by Dave Dice (in hotspot) and me (in j.u.c
in the original jsr166), as the most OS-independent low-level blocking
primitives we could imagine -- it is a leaky one-bit semaphore,
inspired in part from some 1990s DEC SRC papers. My 2004 AQS paper
http://gee.cs.oswego.edu/dl/papers/aqs.pdf includes some discussion.

BTW, on linux, it should be more efficient to implement using
Futex instead of the current scheme based on original Solaris
version. But no one has ever volunteered to do this.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Brian S O'Neill-3
What would be the potential wins from using a Futex directly? By the
time park/unpark is called (from AQS et al), the thread has determined
that the expensive operation must be performed. Is there any step that
the Futex could potentially bypass?

On 2017-08-25 04:12 AM, Doug Lea wrote:

> On 08/25/2017 05:37 AM, Andrew Haley wrote:
>> At the bottom of every blocking operation in j.u.c is the park/unpark
>> pair.  I'm curious about the choice of these primitives.
>
> They were introduced by Dave Dice (in hotspot) and me (in j.u.c
> in the original jsr166), as the most OS-independent low-level blocking
> primitives we could imagine -- it is a leaky one-bit semaphore,
> inspired in part from some 1990s DEC SRC papers. My 2004 AQS paper
> http://gee.cs.oswego.edu/dl/papers/aqs.pdf includes some discussion.
>
> BTW, on linux, it should be more efficient to implement using
> Futex instead of the current scheme based on original Solaris
> version. But no one has ever volunteered to do this.
>
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
In reply to this post by Doug Lea
On 25/08/17 12:12, Doug Lea wrote:
> BTW, on linux, it should be more efficient to implement using
> Futex instead of the current scheme based on original Solaris
> version. But no one has ever volunteered to do this.

I've done it, and could not measure any difference.  In the case where
the kernel blocks, the additional savings from not doing the
mutex/condvar are small: syscall overhead dominates.  In the case
where we return immediately it makes no difference because we (almost)
never get as far as the futex call.  So I never submitted the patch.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Doug Lea
On 08/25/2017 11:12 AM, Andrew Haley wrote:
> On 25/08/17 12:12, Doug Lea wrote:
>> BTW, on linux, it should be more efficient to implement using
>> Futex instead of the current scheme based on original Solaris
>> version. But no one has ever volunteered to do this.
>
> I've done it, and could not measure any difference.
Well, it should still save a few electrons (or millions, across
deployments), so still seems to be the Right Thing to do.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Nathan and Ila Reynolds
Several years ago, I saw Linux futex perform poorly in the kernel. 
Futex was getting a bad rap by others as well.  In my experience, the
kernel would spend a lot of CPU time dealing with futexes.  I do not
remember the circumstances that cause this scenario.  So, I recommend
proceeding with caution and lots of testing.  Perhaps, this caution is
not warranted and the problem was fixed in the kernel.

For the blocking case, I would guess there would not be much difference
in performance.

I recommend running some microbenchmark tests for the non-blocking case
(i.e. unpark() before park()).  You might see a CPU performance gain.

-Nathan

On 8/25/2017 10:28 AM, Doug Lea wrote:

> On 08/25/2017 11:12 AM, Andrew Haley wrote:
>> On 25/08/17 12:12, Doug Lea wrote:
>>> BTW, on linux, it should be more efficient to implement using
>>> Futex instead of the current scheme based on original Solaris
>>> version. But no one has ever volunteered to do this.
>> I've done it, and could not measure any difference.
> Well, it should still save a few electrons (or millions, across
> deployments), so still seems to be the Right Thing to do.
>
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
On 25/08/17 17:49, Nathan and Ila Reynolds wrote:
> Several years ago, I saw Linux futex perform poorly in the kernel.  
> Futex was getting a bad rap by others as well.  In my experience, the
> kernel would spend a lot of CPU time dealing with futexes.  I do not
> remember the circumstances that cause this scenario.  So, I recommend
> proceeding with caution and lots of testing.  Perhaps, this caution is
> not warranted and the problem was fixed in the kernel.

That's won't help, because Linux mutexes always use futex.  There's
no way to bypass a futex call if you block.

> For the blocking case, I would guess there would not be much difference
> in performance.
>
> I recommend running some microbenchmark tests for the non-blocking case
> (i.e. unpark() before park()).  You might see a CPU performance gain.

Really?  I doubt it, because the park permit flag would be set so the
park() return immediately.  The only time that wouldn't happen is a
narrow race condition between that flag being tested and a mutex being
acquired.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Nathan and Ila Reynolds
Thank you for clarifying the details.  I was not fully up to speed.

Last I heard (and this is old hearing), unpark() had to acquire the
mutex before checking the park permit flag.  From the sound of it, using
futex directly would allow for checking the park permit flag without
acquiring the mutex.  Hence, fewer atomic operations (i.e. no need to
acquire and release the mutex).  However, I could be very wrong since I
have never dug into the details and I am only working off of hearsay.

-Nathan

On 8/25/2017 10:53 AM, Andrew Haley wrote:

> On 25/08/17 17:49, Nathan and Ila Reynolds wrote:
>> Several years ago, I saw Linux futex perform poorly in the kernel.
>> Futex was getting a bad rap by others as well.  In my experience, the
>> kernel would spend a lot of CPU time dealing with futexes.  I do not
>> remember the circumstances that cause this scenario.  So, I recommend
>> proceeding with caution and lots of testing.  Perhaps, this caution is
>> not warranted and the problem was fixed in the kernel.
> That's won't help, because Linux mutexes always use futex.  There's
> no way to bypass a futex call if you block.
>
>> For the blocking case, I would guess there would not be much difference
>> in performance.
>>
>> I recommend running some microbenchmark tests for the non-blocking case
>> (i.e. unpark() before park()).  You might see a CPU performance gain.
> Really?  I doubt it, because the park permit flag would be set so the
> park() return immediately.  The only time that wouldn't happen is a
> narrow race condition between that flag being tested and a mutex being
> acquired.
>

--
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
On 25/08/17 18:01, Nathan and Ila Reynolds wrote:
> Last I heard (and this is old hearing), unpark() had to acquire the
> mutex before checking the park permit flag.  From the sound of it, using
> futex directly would allow for checking the park permit flag without
> acquiring the mutex.  Hence, fewer atomic operations (i.e. no need to
> acquire and release the mutex).  However, I could be very wrong since I
> have never dug into the details and I am only working off of hearsay.

Here's now it works now:

void Parker::park(bool isAbsolute, jlong time) {

  // Optional fast-path check:
  // Return immediately if a permit is available.
  // We depend on Atomic::xchg() having full barrier semantics
  // since we are doing a lock-free update to _counter.
  if (Atomic::xchg(0, &_counter) > 0) return;

... stuff with timers and thread interrupts ...

  // Don't wait if cannot get lock since interference arises from
  // unblocking.  Also. check interrupt before trying wait
  if (Thread::is_interrupted(thread, false) ||
      os::Solaris::mutex_trylock(_mutex) != 0) {
    return;
  }

  if (_counter > 0)  { // no wait needed
    _counter = 0;
    status = os::Solaris::mutex_unlock(_mutex);
    assert(status == 0, "invariant");
    // Paranoia to ensure our locked and lock-free paths interact
    // correctly with each other and Java-level accesses.
    OrderAccess::fence();
    return;
  }

...

  // Do this the hard way by blocking ...
  // See http://monaco.sfbay/detail.jsf?cr=5094058.
  if (time == 0) {
    status = os::Solaris::cond_wait(_cond, _mutex);
  } else {
    status = os::Solaris::cond_timedwait (_cond, _mutex, &absTime);
  }

But even if we had had to lock the mutex to read the _counter, it's
just a CAS which would always succeed unless we were being unparked.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Nathan and Ila Reynolds
So, if we switch this to a futex, then we can get rid of the
cond_wait/cond_timedwait calls.  Is this correct?  If correct, then this
change will slightly reduce CPU usage and probably worth the effort. 
The change may reduce the code complexity and reduce maintenance costs. 
At least, the change will reduce the number of emails about suggesting
that park/unpark uses futexes.  ;)

-Nathan

On 8/25/2017 11:28 AM, Andrew Haley wrote:

> On 25/08/17 18:01, Nathan and Ila Reynolds wrote:
>> Last I heard (and this is old hearing), unpark() had to acquire the
>> mutex before checking the park permit flag.  From the sound of it, using
>> futex directly would allow for checking the park permit flag without
>> acquiring the mutex.  Hence, fewer atomic operations (i.e. no need to
>> acquire and release the mutex).  However, I could be very wrong since I
>> have never dug into the details and I am only working off of hearsay.
> Here's now it works now:
>
> void Parker::park(bool isAbsolute, jlong time) {
>
>    // Optional fast-path check:
>    // Return immediately if a permit is available.
>    // We depend on Atomic::xchg() having full barrier semantics
>    // since we are doing a lock-free update to _counter.
>    if (Atomic::xchg(0, &_counter) > 0) return;
>
> ... stuff with timers and thread interrupts ...
>
>    // Don't wait if cannot get lock since interference arises from
>    // unblocking.  Also. check interrupt before trying wait
>    if (Thread::is_interrupted(thread, false) ||
>        os::Solaris::mutex_trylock(_mutex) != 0) {
>      return;
>    }
>
>    if (_counter > 0)  { // no wait needed
>      _counter = 0;
>      status = os::Solaris::mutex_unlock(_mutex);
>      assert(status == 0, "invariant");
>      // Paranoia to ensure our locked and lock-free paths interact
>      // correctly with each other and Java-level accesses.
>      OrderAccess::fence();
>      return;
>    }
>
> ...
>
>    // Do this the hard way by blocking ...
>    // See http://monaco.sfbay/detail.jsf?cr=5094058.
>    if (time == 0) {
>      status = os::Solaris::cond_wait(_cond, _mutex);
>    } else {
>      status = os::Solaris::cond_timedwait (_cond, _mutex, &absTime);
>    }
>
> But even if we had had to lock the mutex to read the _counter, it's
> just a CAS which would always succeed unless we were being unparked.
>

--
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
On 25/08/17 19:45, Nathan and Ila Reynolds wrote:
> So, if we switch this to a futex, then we can get rid of the
> cond_wait/cond_timedwait calls.  Is this correct?  If correct, then this
> change will slightly reduce CPU usage and probably worth the effort.  

It'll get rid of the mutex_trylock and mutex_unlock calls.  It'll
replace the cond_wait/cond_timedwait calls with futex calls.

> The change may reduce the code complexity and reduce maintenance costs.

Sort of.  The current code, although it has had bugs in the past, is
robust enough that it needs very little maintance.  But I take your
point.

> At least, the change will reduce the number of emails about suggesting
> that park/unpark uses futexes.  ;)

At best, probably.  :-)

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

David Holmes-6
In reply to this post by Doug Lea
Hi Doug,

> -----Original Message-----
> From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Doug Lea
> Sent: Friday, August 25, 2017 9:13 PM
> To: [hidden email]
> Subject: Re: [concurrency-interest] On park and unpark
>
> On 08/25/2017 05:37 AM, Andrew Haley wrote:
> > At the bottom of every blocking operation in j.u.c is the park/unpark
> > pair.  I'm curious about the choice of these primitives.
>
> They were introduced by Dave Dice (in hotspot) and me (in j.u.c in the original jsr166), as the most OS-independent low-level blocking
> primitives we could imagine -- it is a leaky one-bit semaphore, inspired in part from some 1990s DEC SRC papers. My 2004 AQS paper
> http://gee.cs.oswego.edu/dl/papers/aqs.pdf includes some discussion.
>
> BTW, on linux, it should be more efficient to implement using Futex instead of the current scheme based on original Solaris version.
> But no one has ever volunteered to do this.

We've been trying to consolidate  and share as much common code as possible on "posix" supporting platforms and recently refactored things to share the PlatformEvent and Parker code (8174231). So to me there would have to be a big win in using futex directly to justify using a custom implementation.

Cheers,
David
 
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
On 25/08/17 23:29, David Holmes wrote:

> We've been trying to consolidate and share as much common code as
> possible on "posix" supporting platforms and recently refactored
> things to share the PlatformEvent and Parker code (8174231). So to
> me there would have to be a big win in using futex directly to
> justify using a custom implementation.

That seems rather surprising to me: HotSpot has always allowed (nay,
even encouraged) back ends to use custom code for performance reasons,
and has never insisted that there must be a "big win".  At least as
long as I can remember.  If there's been a change of policy in this
area it should be up for discussion.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

David Holmes-6
Hi Andrew,

> -----Original Message-----
> From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Andrew Haley
> Sent: Saturday, August 26, 2017 7:03 PM
> To: [hidden email]
> Subject: Re: [concurrency-interest] On park and unpark
>
> On 25/08/17 23:29, David Holmes wrote:
>
> > We've been trying to consolidate and share as much common code as
> > possible on "posix" supporting platforms and recently refactored
> > things to share the PlatformEvent and Parker code (8174231). So to me
> > there would have to be a big win in using futex directly to justify
> > using a custom implementation.
>
> That seems rather surprising to me: HotSpot has always allowed (nay, even encouraged) back ends to use custom code for
> performance reasons, and has never insisted that there must be a "big win".  At least as long as I can remember.  If there's been a
> change of policy in this area it should be up for discussion.

To me "performance reasons" == "big win". You don't introduce specialized, harder to maintain, platform specific code, unless there is a good reason to. I don't think there has been any "change in policy" here - not that there has really been a "policy" as such.

David
 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrew Haley
On 26/08/17 23:56, David Holmes wrote:
>> On 25/08/17 23:29, David Holmes wrote:
>>
>>> We've been trying to consolidate and share as much common code as
>>> possible on "posix" supporting platforms and recently refactored
>>> things to share the PlatformEvent and Parker code (8174231). So to
>>> me there would have to be a big win in using futex directly to
>>> justify using a custom implementation.

>> That seems rather surprising to me: HotSpot has always allowed
>> (nay, even encouraged) back ends to use custom code for performance
>> reasons, and has never insisted that there must be a "big win".  At
>> least as long as I can remember.  If there's been a change of
>> policy in this area it should be up for discussion.

> To me "performance reasons" == "big win". You don't introduce
> specialized, harder to maintain, platform specific code, unless
> there is a good reason to. I don't think there has been any "change
> in policy" here - not that there has really been a "policy" as such.

Okay, but "big win" is IMO raising the bar much too high.  Efficient
systems are composed of thousands of tiny incremental improvements,
each one of which may be too small to measure on its own.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrig Miller
In reply to this post by Nathan and Ila Reynolds
I know of a futex performance issue that remains in the kernel.  Whenever futex is called when the JVM is running in a virtual machine it performs very poorly.  In the particular case that made me aware of this issue, the slowdown was 50%.

To my knowledge, the kernel engineers have never been able to come up with a way to fix this issue.

Andy

On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <[hidden email]> wrote:
Several years ago, I saw Linux futex perform poorly in the kernel.  Futex was getting a bad rap by others as well.  In my experience, the kernel would spend a lot of CPU time dealing with futexes.  I do not remember the circumstances that cause this scenario.  So, I recommend proceeding with caution and lots of testing.  Perhaps, this caution is not warranted and the problem was fixed in the kernel.

For the blocking case, I would guess there would not be much difference in performance.

I recommend running some microbenchmark tests for the non-blocking case (i.e. unpark() before park()).  You might see a CPU performance gain.

-Nathan


On 8/25/2017 10:28 AM, Doug Lea wrote:
On 08/25/2017 11:12 AM, Andrew Haley wrote:
On 25/08/17 12:12, Doug Lea wrote:
BTW, on linux, it should be more efficient to implement using
Futex instead of the current scheme based on original Solaris
version. But no one has ever volunteered to do this.
I've done it, and could not measure any difference.
Well, it should still save a few electrons (or millions, across
deployments), so still seems to be the Right Thing to do.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
-Nathan


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

David Holmes-6

Hi Andy,

 

Can you elaborate further on this issue?

 

But given futex is also the underpinning of the pthread mutex/condvar, wouldn’t you see the same slow down in either case? Or is there something specific about calling futex API directly from the JVM.

 

Thanks,

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Andrig Miller
Sent: Wednesday, September 6, 2017 3:45 AM
To: Nathan and Ila Reynolds <[hidden email]>
Cc: Concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] On park and unpark

 

I know of a futex performance issue that remains in the kernel.  Whenever futex is called when the JVM is running in a virtual machine it performs very poorly.  In the particular case that made me aware of this issue, the slowdown was 50%.

 

To my knowledge, the kernel engineers have never been able to come up with a way to fix this issue.

 

Andy

 

On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <[hidden email]> wrote:

Several years ago, I saw Linux futex perform poorly in the kernel.  Futex was getting a bad rap by others as well.  In my experience, the kernel would spend a lot of CPU time dealing with futexes.  I do not remember the circumstances that cause this scenario.  So, I recommend proceeding with caution and lots of testing.  Perhaps, this caution is not warranted and the problem was fixed in the kernel.

For the blocking case, I would guess there would not be much difference in performance.

I recommend running some microbenchmark tests for the non-blocking case (i.e. unpark() before park()).  You might see a CPU performance gain.

-Nathan



On 8/25/2017 10:28 AM, Doug Lea wrote:

On 08/25/2017 11:12 AM, Andrew Haley wrote:

On 25/08/17 12:12, Doug Lea wrote:

BTW, on linux, it should be more efficient to implement using
Futex instead of the current scheme based on original Solaris
version. But no one has ever volunteered to do this.

I've done it, and could not measure any difference.

Well, it should still save a few electrons (or millions, across
deployments), so still seems to be the Right Thing to do.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

--
-Nathan



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



 

--

Andrig (Andy) T. Miller

Global Platform Director, Middleware

Red Hat, Inc.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: On park and unpark

Andrig Miller
It took some digging but I found the original bugzilla for this issue.  It was the JVM running in a KVM guest, on RHEL 6.4.  Unfortunately, all the details are mostly private, because it originated with a Red Hat customer case.

Having said that, the issue seems to be related to how the paravirtualized kernel deals with interrupts and scheduling as a result of the futex call.  The interesting thing here, is that no one was able to actually solve it with experimental kernel patches.  Lot's of things were tried, but none truly succeeded.

The issue eventually was just closed as "WON'T FIX".  Looked more like, "CAN'T FIX" to me.

So, it is an isolated issue, and perhaps it doesn't even happen anymore, but since I remembered this issue, I wanted to let everyone know.

Andy



On Tue, Sep 5, 2017 at 2:56 PM, David Holmes <[hidden email]> wrote:

Hi Andy,

 

Can you elaborate further on this issue?

 

But given futex is also the underpinning of the pthread mutex/condvar, wouldn’t you see the same slow down in either case? Or is there something specific about calling futex API directly from the JVM.

 

Thanks,

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Andrig Miller
Sent: Wednesday, September 6, 2017 3:45 AM
To: Nathan and Ila Reynolds <[hidden email]>
Cc: Concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] On park and unpark

 

I know of a futex performance issue that remains in the kernel.  Whenever futex is called when the JVM is running in a virtual machine it performs very poorly.  In the particular case that made me aware of this issue, the slowdown was 50%.

 

To my knowledge, the kernel engineers have never been able to come up with a way to fix this issue.

 

Andy

 

On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <[hidden email]> wrote:

Several years ago, I saw Linux futex perform poorly in the kernel.  Futex was getting a bad rap by others as well.  In my experience, the kernel would spend a lot of CPU time dealing with futexes.  I do not remember the circumstances that cause this scenario.  So, I recommend proceeding with caution and lots of testing.  Perhaps, this caution is not warranted and the problem was fixed in the kernel.

For the blocking case, I would guess there would not be much difference in performance.

I recommend running some microbenchmark tests for the non-blocking case (i.e. unpark() before park()).  You might see a CPU performance gain.

-Nathan



On 8/25/2017 10:28 AM, Doug Lea wrote:

On 08/25/2017 11:12 AM, Andrew Haley wrote:

On 25/08/17 12:12, Doug Lea wrote:

BTW, on linux, it should be more efficient to implement using
Futex instead of the current scheme based on original Solaris
version. But no one has ever volunteered to do this.

I've done it, and could not measure any difference.

Well, it should still save a few electrons (or millions, across
deployments), so still seems to be the Right Thing to do.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

--
-Nathan



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



 

--

Andrig (Andy) T. Miller

Global Platform Director, Middleware

Red Hat, Inc.




--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest