[concurrency-interest] Low-latency pause in JDK

Viktor Klang viktor.klang at gmail.com
Sat Oct 26 07:37:37 EDT 2019


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
:)

On Sat, Oct 26, 2019 at 10:23 AM Francesco Nigro <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> 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> 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
>>>
>>

-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20191026/01325bec/attachment-0001.html>


More information about the Concurrency-interest mailing list