[concurrency-interest] Spin Loop Hint support: Draft JEP proposal (original) (raw)

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.

-Doug

More information about the hotspot-dev mailing list