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

[Vitaly Davidovich]

On Wednesday, February 24, 2016, Gil Tene <gil at azul.com> wrote:

> onXXX is VERY relevant to this situation. And it's exactly that precedent
> and common convention for event notification calls that drove the choice of
> onSpinWait as a method name. onSpinWait() it is delivering a notification
> [from the calling code to the Runtime, or the Thread] about what is going
> on: a spin wait is in progress.

onXXX is typically used for event *handler* names, not event firing.  But
at any rate, this isn't an eventing system.

>
> The fundamental difference between onSpinWait() and Thread.yield() is that
> yield() means "please yield here", while onSpinWait means "I am in the
> middle of busily executing a spin wait that I need no help with, and
> certainly don't want to be blocking in. But you might want to know about
> that and do something with that knowledge. Preferably something that
> improves my performance." Basically, onSpinWait() is delivering a
> notification of a situation, and the runtime has a chance to react to that.

You can just as well think of spinWait as"I'm spin waiting *right here,
right now*, please possibly do something or nothing", which is just like
yield.

Here's the bottom line as I see it.  This API is for advanced/expert users,
there's no need for additional fluff.These users will either already know
what this API translates to on platforms they care about or will seek that
info.  Users unfamiliar with the JDK will see spinWait or onSpinWait -
neither name alone is sufficient to figure out what it is, they'll look at
javadoc which is the right place for elaboration.  So the 'on' prefix adds
no additional *practical* value for the intended audience, it's just
noise.  Runtime has just gc(), not onGC, even though it also can do
nothing, run GC in foreground, run GC in background, or anything else.
Again, 'on' would add zero practical value.

If you're really keen on having something in the name indicate its
optionality/hint nature, spinWaitHint is better.

>
> Dropping the "on" would completely change the meaning. Something called
> "spinWait" *is* like yield(). It would/should mean "please spin wait here".
> But that's not what spin wait constructs need or want in a call. Unlike
> yield(), spin wait constructs use their own logic for spinning, and usually
> need to retain control over the logic. They just need to let someone know
> that spinning is going on, in the hope that performance of the spinwait
> construct (with whatever logic it uses) might be improved.
>
> Note that the runtime reactions to being notified the calling code is in
> the middle of a spin wait could range from doing nothing, to doing
> something with instruction execution (e.g. execute an x86 pause
> instruction), to doing something more sophisticated (e.g. trying to
> dedicate a core to the spinning thread and steer all other thread and
> interrupts away from it to improve it's reaction time stats). What will
> actually happen is up to the runtime, and intentionally not specified. Per
> the JavaDoc, if the runtime does take action when it receives the
> onSpinWait() event, the action is intended "to improve the performance of
> invoking spin-wait loop constructions".
>
> You can hopefully/probably see why Runtime was a logical choice as the
> receiver of the event. Since Thread is also acceptable and defensible as
> the receiver of the event, I'm happy to go with it if it gets us over this
> name-can-of-worms thing. But please please please don't let us go into a
> whole method name redo again. We've done that on and off for 3+ months, and
> what we have is both logical and "not unacceptable": onSpinWait().
>
> Let's just go with it.

If we're going to discuss naming at all, let's discuss it in earnest rather
than just glossing over it in the name of progress? Yes, if it's between
not having this API at all vs having it named suboptimally (IMO) then I
frankly almost don't care what it's called, as I mentioned before.  But if
we *are* subjecting naming to critique, then let's iron that out.

If you want, run a poll to get a better feel for what others may think.
Doug did that recently for some CompletableFuture behavior change
proposals.  Ultimately, I don't make the call on this anyway so I'm just
giving you my opinion as a would-be user of this API.

>
> Thread.onSpinWait() FTW!
>
> > On Feb 23, 2016, at 8:03 PM, Vitaly Davidovich <vitalyd at gmail.com
> <javascript:;>> wrote:
> >
> > Yes, I was going to mention onXXX being common for event handler names
> (e.g
> > onMouseClick), but didn't bother for the same reason you mentioned - it's
> > irrelevant to this situation.
> >
> > On Tuesday, February 23, 2016, Paul Benedict <pbenedict at apache.org
> <javascript:;>> wrote:
> >
> >> The onXXX prefix does have precedent as event handler callbacks, but
> this
> >> method does not fit that purpose. Thus, I agree dropping "on" is
> sensible.
> >> On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" <vitalyd at gmail.com
> <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com <javascript:;>');>>
> wrote:
> >>
> >>> On Tuesday, February 23, 2016, Doug Lea <dl at cs.oswego.edu
> <javascript:;>
> >>> <javascript:_e(%7B%7D,'cvml','dl at cs.oswego.edu <javascript:;>');>>
> wrote:
> >>>
> >>>> On 02/23/2016 04:30 PM, Vitaly Davidovich wrote:
> >>>>
> >>>>> Why not drop the (superfluous, IMO) "on" prefix while you're changing
> >>> the
> >>>>> receiver?
> >>>>>
> >>>>
> >>>> Because then it reads as if the method itself is doing a spinWait.
> >>>
> >>> vs who else logically speaking? We all know there's a runtime
> underneath
> >>> Java, there's no point in explicitly calling that out here.  Again,
> how is
> >>> this different from Thread::yield or any of the other mentioned
> examples?
> >>> This is splitting hairs perhaps but there's no onXXX precedent to
> follow
> >>> and this just throws an oddly looking method name into the mix.
> >>>
> >>>> "onSpinWait" is the only proposed name that no one has said they
> cannot
> >>>> live with. So, live with it :-)
> >>>
> >>> Perhaps that's because the Runtime placement was a more glaring issue?
> :)
> >>> It's livable but I just don't see the point of the prefix (and yes, I
> read
> >>> the description of the intent in the original mail).
> >>>
> >>>>
> >>>> -Doug
> >>>>
> >>>>
> >>>>
> >>>>> On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene <gil at azul.com
> <javascript:;>
> >>> <javascript:_e(%7B%7D,'cvml','gil at azul.com <javascript:;>');>> wrote:
> >>>>>
> >>>>>
> >>>>>> On Feb 22, 2016, at 10:11 AM, mark.reinhold at oracle.com
> <javascript:;>
> >>> <javascript:_e(%7B%7D,'cvml','mark.reinhold at oracle.com <javascript:;>');>
> wrote:
> >>>>>>>
> >>>>>>> 2016/1/28 9:25 -0800, gil at azul.com <javascript:;>
> >>> <javascript:_e(%7B%7D,'cvml','gil at azul.com <javascript:;>');>:
> >>>>>>>
> >>>>>>>> This thread seems to have "hopped away" to the
> concurrency-interest
> >>>>>>>> list in mid-Dec-2015. This posting is intended to capture a
> summary
> >>> of
> >>>>>>>> reasoning and some of the discussion there so that we have it in
> the
> >>>>>>>> record in core-libs-dev. Mostly by including the contents of
> several
> >>>>>>>> posts in the continuations of the original thread.
> >>>>>>>>
> >>>>>>>> See thread continuations here:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576
> >>>>>>
> >>>>>>> and here:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580
> >>>>>>
> >>>>>>>
> >>>>>>>> Summary:
> >>>>>>>>
> >>>>>>>> ...
> >>>>>>>>
> >>>>>>>
> >>>>>>> Thanks for the summary.
> >>>>>>>
> >>>>>>> I still don't buy the argument that this method belongs in
> >>> j.l.Runtime.
> >>>>>>>
> >>>>>>> To say that this method should go there because it's an instruction
> >>> to
> >>>>>>> the run-time system is pretty weak.  I agree with Vitaly [1] that
> if
> >>>>>>> that's the threshold for adding methods to the Runtime class then
> >>> lots
> >>>>>>> of other stuff belongs there as well, including much of what's now
> in
> >>>>>>> java.lang.Thread and java.util.concurrent and, arguably, anything
> >>> else
> >>>>>>> related to interacting with the environment in which the
> application
> >>>>>>> runs (file and network I/O, process manipulation, etc.).
> >>>>>>>
> >>>>>>> This thread-related method really belongs in either
> java.lang.Thread
> >>> or
> >>>>>>> java.util.concurrent.LockSupport.  j.l.Thread already has plenty of
> >>>>>>> expert-level static methods related to the current thread, one of
> >>> which
> >>>>>>> (Thread::yield) is even a hint, just like this one.
> >>> j.u.c.LockSupport
> >>>>>>> is even more obviously intended for expert users and hence may be
> the
> >>>>>>> best choice, but I could live with either one.
> >>>>>>>
> >>>>>>
> >>>>>> Ok. In the interest of moving forward, lets settle on:
> >>>>>>
> >>>>>> Thread.onSpinWait()
> >>>>>>
> >>>>>> Same logic for the name, different receiver for the event. I can
> >>>>>> certainly
> >>>>>> live with it, and Doug seems ok with it as well.
> >>>>>>
> >>>>>> — Gil.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Sent from my phone
> >>>
> >>
> >
> > --
> > Sent from my phone
>
>

-- 
Sent from my phone