Spin Loop Hint support: Draft JEP proposal

Doug Lea dl at cs.oswego.edu
Thu Oct 8 10:58:04 UTC 2015

On 10/06/2015 09:28 PM, Gil Tene wrote:
> As for fitting in with larger-picture or theme things (listed above). I think that
> agonizing over the choice of where to put this is important

To avoid the kinds of problems we later saw when basic JVM methods were
placed in odd places just for the sake of appearances (e.g., park/unpark),
the best choice seems to be class Thread, as in:

class Thread { //
    * A hint to the platform that the current thread is momentarily
    * unable to progress. ... add more guidance ...
   void spinYield();

In principle, this would also allow the implementation to do an actual
yield on uniprocessors or when the load average is high. Probably not
in initial implementation though.

Adding a method to class Thread risks name clashes with existing
methods introduced in subclasses. So this might need a clunkier name
to effectively eliminate the possibility.

An analogous method could also be added (now or later)
for MWAIT-based support for waits on the thread's park semaphore
(which is more tractable than doing so for an arbitrary variable).

An alternative to either is to add optional arguments to
yield and park providing a hint about whether to context-switch.

Joe Darcy: Thread.yield does set a precedent here:

* A hint to the scheduler that the current thread is willing to yield
* its current use of a processor. The scheduler is free to ignore this
* hint.


More information about the core-libs-dev mailing list