Spin Loop Hint support: Draft JEP proposal

[Kirk Pepperdine]

Hi Doug,

Brilliant thought, absolutely…. so obvious that it is completely hidden in plain sight. In the past dumping these things into unsafe was a huge mistake. It’s like a back alley for homeless behavior. If you think about it, it’s the thread that would be spinning so it’s obviously the thread that needs the hint. It should own the behavior… Very clear thinking.

Regards,
Kirk

> On Oct 8, 2015, at 12:58 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> 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.
> 
> 
> -Doug
>