[concurrency-interest] spinLoopHint() JEP draft discussion

Gil Tene gil at azulsystems.com
Tue Oct 6 21:41:47 EDT 2015


When comparing spinLoopHint() to Thread.yield(), we're talking about different orders of magnitude, and different motivations.

On the motivation side: A major reason for using spinLoopHint() is to improve the reaction time of a spinning thread (from the time the event it is spinning for actually occurs until it actually reacts to it). Power savings is a another benefit. Thread.yield() doesn't help with either.

On the orders of magnitude side: Thread.yield involves making a system call. This makes it literally 10x+ longer to react than spinning without it, and certainly pulls in the opposite direction of spinLoopHint().

> On Oct 6, 2015, at 1:15 PM, Nathan Reynolds <nathan.reynolds at oracle.com> wrote:
> 
> I am not fully up to speed on this topic.  However, why not call Thread.yield()?  If there are no other threads waiting to get on the processor, then Thread.yield() does nothing.  The current thread keeps executing.  If there are threads waiting to get on the processor, then current thread goes to the end of the run queue and another thread gets on the processor (i.e. a context switch).  The thread will run again after the other threads ahead of it either block, call yield() or use up their time slice.  The only time Thread.yield() will do anything is if *all* of the processors are busy (i.e. 100% CPU utilization for the machine).  You could run 1000s of threads in tight Thread.yield() loops and all of the threads will take a turn to go around the loop one time and then go to the end of the run queue.
> 
> I've tested this on Windows and Linux (Intel 64-bit processors).
> 
> Some people are very afraid of context switches.  They think that context switches are expensive.  This was true of very old Linux kernels.  Now a days, it costs 100s of nanoseconds to do a context switch.  Of course, the cache may need to be reloaded with the data relevant for the running thread.
> -Nathan
> On 10/6/2015 11:56 AM, Gil Tene wrote:
>> A variant of synchronic for j.u.c would certainly be cool to have. Especially if it supports a hint that makes it actually spin forever rather than block (this may be what expect_urgent means, or maybe a dedicated spin level is needed). An implementation could use spinLoopHint() under the hood, or other things where appropriate (e.g. if MWAIT was usefully available in user mode in some future, and had a way to limit the wait time).
>> 
>> However, an abstraction like synchronic is a bit higher level than spinLoopHint(). One of the main drivers for spinLoopHint() is direct-use cases by programs and libraries outside of the core JDK. E.g. spinning indefinitely (or for limited periods) on dedicated vcores is a common practice in high performance messaging and communications stacks, as is not unreasonable on today's many-core systems. E.g. seeing 4-8 threads "pinned" with spinning loops is common place in trading applications, in kernel bypass network stacks, and in low latency messaging. And the conditions for spins are often more complicated than those expressible by synchronic (e.g. watching multiple addresses in a mux'ed spin). I'm sure a higher level abstraction for a spin wait can be enriched enough to come close, but there are many current use cases that aren't covered by any currently proposed abstraction.
>> 
>> So, I like the idea of an abstraction that would allow uncomplicated spin-wait use, but I also think that direct access to spinLoopHint() is very much needed. They don't contradict each other.
>> 
>> — Gil.
>> 
>>> On Oct 6, 2015, at 9:49 AM, Hans Boehm < <mailto:boehm at acm.org>boehm at acm.org <mailto:boehm at acm.org>> wrote:
>>> 
>>> If you haven't seen it, you may also be interested in
>>> 
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0126r0.pdf <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0126r0.pdf>
>>> 
>>> which seems to be a very different perspective on roughly the same space.
>>> 
>>> On Tue, Oct 6, 2015 at 8:11 AM, Gil Tene < <mailto:gil at azulsystems.com>gil at azulsystems.com <mailto:gil at azulsystems.com>> wrote:
>>> I posted a draft JEP about adding spinLoopHint() for discussion on core-libs-dev and hotspot-dev. May be of interest to this group. The main focus is supporting outside-of-the-JDK spinning needs (for which there are multiple eager users), but it could/may be useful under the hood in j.u.c.
>>> 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035613.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035613.html>
>>> 
>>> See draft JEP, tests, and links to prototype JDKs to play with here:
>>> https://github.com/giltene/GilExamples/tree/master/SpinHintTest <https://github.com/giltene/GilExamples/tree/master/SpinHintTest>
>>> 
>>> — Gil.
>>> 
>>> _______________________________________________
>>> 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 <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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 <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
> 
> _______________________________________________
> 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/20151007/031ed833/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151007/031ed833/attachment.bin>


More information about the Concurrency-interest mailing list