Spin Loop Hint support: Draft JEP proposal

[Peter Levart]

On 10/05/2015 05:19 PM, Andrew Haley wrote:
> 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.
>
> Andrew.

Yes, perhaps park/unpark is already to high-level as it requires Thread 
to be passed to unpark and therefore requires a thread to publish itself 
before doing park(), etc. Spin-looping is usually used without thread 
bookkeeping.

I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be 
called. Just before entering the spin-loop or at each iteration of the 
loop? Is this some kind of CPU.yield() (by analogy to Thread.yield())?

Regards, Peter