[concurrency-interest] Low-latency pause in JDK

Doug Lea dl at cs.oswego.edu
Sat Oct 26 14:07:05 EDT 2019

On 10/26/19 7:37 AM, Viktor Klang via Concurrency-interest wrote:
> Given that the strategy will depend on the runtime environment, a JDK
> "intrinsic" would make most sense to me—hence wanting something in the
> JDK :)

Considering that a general solution would provide the best course of
action whenever entities (for example you, or some thread) momentarily
cannot get something they momentarily want (a lock, a new JDK method),
this is a hard request to fulfill! The best we've been able to do is
make internal choices (in locks, queues, etc) that are OK with respect
to more concrete contexts. In addition to issues that other people have
mentioned, solutions also interact with choice of garbage collector.

I agree that it might be would be nice to expose some of the lower-level
features available on some platforms that might sometimes provide better
performance, but these also tend to be hard to encapsulate in APIs in
ways that do more good than harm. (For example, I have later removed
nearly every occurrence of Thread.yield() in any code I've written after
finding something better or more general.)

And as always (especially in real life), whenever you encounter a
problem involving blocking, the main question to ask is whether there is
something you can do other than block -- helping, choosing alternate
actions, speculating, etc.


> On Sat, Oct 26, 2019 at 10:23 AM Francesco Nigro <nigro.fra at gmail.com
> <mailto:nigro.fra at gmail.com>> wrote:
>     I mean RDTSC, missed the final C :P
>     Il sab 26 ott 2019, 12:07 Francesco Nigro <nigro.fra at gmail.com
>     <mailto:nigro.fra at gmail.com>> ha scritto:
>         I was hoping that for parking times <  granularity offered by
>         the OS would make sense a mm_pause (possibility not broken) spin
>         loop while using rdts to measure the elapsed time (+ lfence, if
>         needed, but maybe with the pause isn't necessary). And no
>         safepoint polls in the spin wait loop. 
>         I know that on oversubscribed systems (more active threads then
>         core) isn't a great solution but would be nice to have some way
>         to perform a low latency sleep.
>         Implementing by myself saving the safepoint poll to be injected
>         in an uncounted loop is not that trivial...
>         Il sab 26 ott 2019, 11:23 Andrew Haley via Concurrency-interest
>         <concurrency-interest at cs.oswego.edu
>         <mailto:concurrency-interest at cs.oswego.edu>> ha scritto:
>             On 10/25/19 11:11 AM, Viktor Klang via Concurrency-interest
>             wrote:
>             >
>             > Is there any jdk-builtin Java8+ method which tries to be
>             clever
>             > about low-nanos/micros parking?
>             >
>             > I'm currently considering LockSupport.parkNanos but want
>             to avoid
>             > having the Thread parked when parking + wake-up latency is
>             more
>             > likely to be much greater than the requested time.
>             >
>             > I.e. some combination of onSpinWait + some non-cache-polluting
>             > computation + yielding + actual parking. I'd like to avoid
>             having to
>             > custom-roll it, hence the question for prior art ;)
>             As I understand it, the common wisdom is to wait for about
>             half the
>             round-trip time for a system call and then park. It doesn't
>             sound
>             terribly hard to write something to do that.
>             Please forgive me for digressing, but:
>             Arm has a mechanism to do this, WFE. When a core fails to
>             obtain a
>             lock it executes a WFE instruction which waits on the cache line
>             containing the lock. When that cache line is written to by
>             the core
>             releasing the lock it awakens the waiting core.
>             I'd like to find some way to expose this in a high-level
>             language but
>             it's not at all easy to do.
>             I believe that Intel has MWAIT which is similar, but it's a
>             privileged
>             instruction so no use to us.
>             -- 
>             Andrew Haley  (he/him)
>             Java Platform Lead Engineer
>             Red Hat UK Ltd. <https://www.redhat.com>
>             https://keybase.io/andrewhaley
>             EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>             _______________________________________________
>             Concurrency-interest mailing list
>             Concurrency-interest at cs.oswego.edu
>             <mailto:Concurrency-interest at cs.oswego.edu>
>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> -- 
> Cheers,
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list