[concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Doug Lea dl at cs.oswego.edu
Thu Oct 15 15:32:09 UTC 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 core-libs-dev mailing list