Spin Loop Hint support: Draft JEP proposal

Vitaly Davidovich vitalyd at gmail.com
Thu Oct 8 14:39:30 UTC 2015


I agree with David that it should be static though; it doesn't really make
sense to be instance.

sent from my phone
On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" <kirk.pepperdine at gmail.com>
wrote:

> 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
> >
>
>



More information about the core-libs-dev mailing list