Spin Loop Hint support: Draft JEP proposal (original) (raw)

Peter Levart peter.levart at gmail.com
Mon Oct 5 15:40:34 UTC 2015

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

More information about the core-libs-dev mailing list