Spin Loop Hint support: Draft JEP proposal

[Andrew Haley]

On 05/10/15 21:43, Gil Tene wrote:

> I see SpinLoopHint as very separate from things like MONITOR/WAIT
> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice
> way until this state changes" instructions that other architectures
> may have or add.
>
> Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to
> potentially wait for specific state changes to occur. As such, they
> can be used to implement a specific form of a spin loop (the most
> common one, probably). But they do not provide for generic spinning
> forms. E.g. loops that have multiple exit conditions in different
> memory locations, loops that wait on internal state changes that are
> no affected by other CPUs (like "spin only this many times before
> giving up" or "spin for this much time"), and loops that may use
> transactional state changes (e.g. LOCK XADD, or wider things with
> TSX) are probably "hard" to model with these instructions.

Yes, you're right: there's no real way to combine these things, and
support for WFE requires some other kind of interface -- if I ever
manage to think of a nice way to express it in Java.  So, my
apologies for hijacking this thread, but now you've got me thinking.

In an ideal world there would be a timer associated with WFE which
would trigger after a short while and allow a thread to be
descheduled.  However, it is possible to set a periodic timer which
regularly signals each worker thread, giving it the opportunity to
block if unused for a long time.  This should make a much more
responsive thread pool, so that when worker threads are active they
respond in nanoseconds rather than microseconds.

[ An aside: WFE is available in user mode, and according to Intel's
documentation it should be possible to configre an OS to use
MONITOR/WAIT in user mode too.  I don't know why it doesn't work. ]

Andrew.