Spin Loop Hint support: Draft JEP proposal

Andrew Haley aph at redhat.com
Mon Oct 5 15:19:38 UTC 2015

On 10/05/2015 03:59 PM, Peter Levart wrote:
> On 10/05/2015 11:41 AM, Andrew Haley wrote:
>> Hi Gil,
>> On 04/10/15 17:22, Gil Tene wrote:
>>> Summary
>>> Add an API that would allow Java code to hint that a spin loop is
>>> being executed.
>> I don't think this will work for ARM, which has a rather different
>> spinlock mechanism.
>> Instead of PAUSE, we wait on a lock word with WFE.  WFE puts a core
>> into a lightweight sleep state waiting on a particular address (the
>> lock word) and a write to the lock word wakes it up.  This is very
>> useful and somewhat analogous to 86's MONITOR/MWAIT.
>> I can't immediately see how to generalize your proposal to ARM,
>> which is a shame.
> Just a thought...
> ARM WaitForEvent/SendEvent instructions sound like a kind of 
> park/unpark, but on a CPU-core-level (WFE) and global system-level 
> (SendEvent).

Pretty much, although the wakeup is just a store.

> I wonder whether it would be possible to use them to optimize the
> latency of the implementation of park/unpark. The same goes for Spin
> Loop Hint. Would it be possible to incorporate spin-looping in the
> park/unpark implementation for x86 itself? Higher-level
> synchronization constructs (like locks, synchronizers, etc..) would
> then just use park/unpark and not bother with spin-looping
> themselves.

I spent a while thinking about that, and I'm not sure it's possible.
WFE can wait for a very long time, and there is a general presumption
that if a thread blocks it really should be descheduled rather than
hog a core with a WFE.  WFE is excellent if you have many cores (more
cores than threads) and don't mind dedicating them to particular
tasks: it's great for fork/join thread pools, etc, because it doesn't
have the overhead of blocking and unblocking.  Maybe the best thing
would be a different version of park/unpark.


More information about the core-libs-dev mailing list