[concurrency-interest] Low-latency pause in JDK

Francesco Nigro nigro.fra at gmail.com
Sat Oct 26 06:07:26 EDT 2019


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> 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20191026/42ecb4c2/attachment.html>


More information about the Concurrency-interest mailing list