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. In contrast, spinLoopHint() is intended to hint that the loop it is in is spinning, regardless of the logic used for the spinning or the spin termination. It is useful, for example, in heuristic spinning-before-blocking situations, where WFE/SEV MONITOR/WAIT would not be appropriate. MONITOR/MWAIT and WFE/SEV would be a good way to implement an actual spinning test or atomic operation (if it were available in user mode, but alas it isn't). And I could see some variant of AtomicX.CompareAndSet being proposed to use them, but the semantics and context are different. There are at least two architectures for which spinLoophint() is both a natural fit as well as the way everything else (kernels, libraries) seem to be spinning: In x86, the PAUSE instruction is a classic example of the spinLoopHint() use case. On some PowerPC implementations with multiple hardware threads (HMT), a lowering of the hardware thread priority is probably another example of a good use for spinLoopHint() [I haven't tried or tested this for spinLoopHint(), but that's what the linux kernel spinloops do for example: http://lxr.free-electrons.com/source/arch/powerpc/include/asm/spinlock.h?v=2.6.35#L116]. On some CPUs there might not (or not yet) be equivalent operation. A nop would be a valid way to implement it on current ARM. — Gil. > On Oct 5, 2015, at 2:41 AM, Andrew Haley <a...@redhat.com> 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. > > Andrew. >
