[concurrency-interest] Spin Loop Hint support: Draft JEP proposal
dl at cs.oswego.edu
Thu Oct 15 11:32:09 EDT 2015
On 10/14/2015 11:53 PM, Gil Tene wrote:
> I agree on the separation between spin-hinting and monitor-like constructs.
> But not so much on the analogy to or use of the term "yield" to describe what
> is intended y spin hints.
I've been focussing on the spec, which still seems to best support
this naming. Let's try fleshing out some more (for no-arg version).
* A hint to the platform that the current thread is momentarily
* unable to progress until the occurrence of one or more actions
* of one or more other threads. The method is mainly applicable
* in spin-then-block constructions entailing a bounded number
* of re-checks of a condition, separated by spinYield(), followed
* if necessary with use of a blocking synchronization mechanism.
public static void spinYield();
What should be the response to this hint? When applicable
and available, the JVM should just issue PAUSE. But on a uniprocessor,
or when load average is easily detected to be high, or
on a tightly packed cloud node, a plain yield or something
along those lines might be a better use of this hint, that
the spec should not rule out. Also, I believe that some x86
hypervisors intercept PAUSE and do something roughly similar
after repeated invocations.
> While the spinYield() example in your e-mail below can work from a semantic
> point of view in the same code, IMO the word "yield" suggests the exact
> opposite of what spnLoopHint() is intending to do or hint at
Maybe. If you are on a system with load > #cpus, or with
certain forms of hypervisor, or without a PAUSE instruction,
spinYield might not improve responsiveness but might still
improve system throughput.
More information about the Concurrency-interest