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

[Andrew Dinn]

On 24/02/16 15:56, mark.reinh...@oracle.com wrote:
> 2016/2/23 22:22 -0800, Gil Tene :
>> ...
>>
>> Let's just go with it.
>>
>> Thread.onSpinWait() FTW!
> 
> I agree.  The "on" prefix is not exclusively reserved for APIs that
> deliver event objects, and in this context it clarifies the meaning
> of the method.

Hallelujah, now we can start painting the bike shed!

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)

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

[Ivan Krylov]

On 24/02/2016 18:56, mark.reinh...@oracle.com wrote:

2016/2/23 22:22 -0800, Gil Tene :

...

Let's just go with it.

Thread.onSpinWait() FTW!

I agree.  The "on" prefix is not exclusively reserved for APIs that
deliver event objects, and in this context it clarifies the meaning
of the method.

- Mark

I have updated the JEP: https://bugs.openjdk.java.net/browse/JDK-8147832

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

[Vitaly Davidovich]

Looks like you have Mark's approval, so we're done :).

On Wed, Feb 24, 2016 at 11:06 AM, Ivan Krylov  wrote:

> On 24/02/2016 18:20, Vitaly Davidovich wrote:
>
>> 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.
>>
> This discussion has been going on for nearly half of a year, everyone is
> saying "I don't care for the name, but..".
> Another poll will not do any good. I would rather have a Project Lead to
> make a final decision on the API, a harmless one either way IMO.
>
> Ivan
>
>

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

[Ivan Krylov]

On 24/02/2016 18:20, Vitaly Davidovich wrote:
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. 
This discussion has been going on for nearly half of a year, everyone is 
saying "I don't care for the name, but..".
Another poll will not do any good. I would rather have a Project Lead to 
make a final decision on the API, a harmless one either way IMO.


Ivan

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

[mark . reinhold]

2016/2/23 22:22 -0800, Gil Tene :
> ...
> 
> Let's just go with it.
> 
> Thread.onSpinWait() FTW!

I agree.  The "on" prefix is not exclusively reserved for APIs that
deliver event objects, and in this context it clarifies the meaning
of the method.

- Mark

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

[Vitaly Davidovich]

On Wednesday, February 24, 2016, Gil Tene  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  > 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  > 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"  

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

[Gil Tene]

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.

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.

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.

Thread.onSpinWait() FTW!

> On Feb 23, 2016, at 8:03 PM, Vitaly Davidovich  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  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" > > wrote:
>> 
>>> On Tuesday, February 23, 2016, Doug Lea >> > 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 >> > wrote:
> 
> 
>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com
>>>  wrote:
>>> 
>>> 2016/1/28 9:25 -0800, g...@azul.com
>>> :
>>> 
 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

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

[Vitaly Davidovich]

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  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"  > wrote:
>
>> On Tuesday, February 23, 2016, Doug Lea > > 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 > > wrote:
>> >>
>> >>
>> >>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com
>>  wrote:
>> 
>>  2016/1/28 9:25 -0800, g...@azul.com
>> :
>> 
>> > 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

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

[Paul Benedict]

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"  wrote:

> On Tuesday, February 23, 2016, Doug Lea  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  wrote:
> >>
> >>
> >>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:
> 
>  2016/1/28 9:25 -0800, g...@azul.com:
> 
> > 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
>

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

[Vitaly Davidovich]

On Tuesday, February 23, 2016, Doug Lea  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  wrote:
>>
>>
>>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:

 2016/1/28 9:25 -0800, g...@azul.com:

> 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

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

[Doug Lea]

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.
"onSpinWait" is the only proposed name that no one has said they cannot
live with. So, live with it :-)

-Doug




On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene  wrote:




On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:

2016/1/28 9:25 -0800, g...@azul.com:

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.

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

[Vitaly Davidovich]

Why not drop the (superfluous, IMO) "on" prefix while you're changing the
receiver? Thread::spinWait would be in the same style/spirit as
Thread::yield, and I don't think there will be much contention.

On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene  wrote:

>
> > On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:
> >
> > 2016/1/28 9:25 -0800, g...@azul.com:
> >> 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.
>

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

[Gil Tene]

> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:
> 
> 2016/1/28 9:25 -0800, g...@azul.com:
>> 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.

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

[David M. Lloyd]

On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote:

2016/1/28 9:25 -0800, g...@azul.com:

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.


I agree, and I would also point out (perhaps redundantly?) that there 
was talk on concurrency-interest of possibly relocating or replicating 
the park/unpark statics into j.l.Thread, which further strengthens the 
idea that Thread is the best place for things like this.


--
- DML

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

[mark . reinhold]

2016/1/28 9:25 -0800, g...@azul.com:
> 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.

- Mark


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038400.html

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

[Gil Tene]

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:

On the reasoning for moving from Thread.SpinLoopHint to Runtime.onSpinWait:

From Gil Tene, on Tue, Dec 1, 2015 at 3:45 PM
> …
> Thread.spinLoopHint() was my first choice as well. But I was swayed by strong 
> arguments against "hint" in the method name. Including the lack of "action" 
> and ambiguity about roles. We looked at various names that were either clear 
> and way too long or way too short or implementation specific (or narrowing), 
> like skip, pause, relax, etc.
> 
> Given the spec we agreed on, the name we were looking for was something that 
> would be equivalent to the obvious expectations from something named as 
> elaborately as:
> 
> maybeYouShouldTryToImproveThePerformanceOfTheSpinWaitLoopMakingThisCall(), 
> with the receiver being either the thread or the runtime.
> 
> The "maybe you should try" part is important because doing nothing is a valid 
> option, and accidentally failing to achieve the goal is probably ok, but 
> consistently working in the opposite direction of the goal would be 
> "surprising behavior". The "...making this call" part is important because of 
> ambiguities around roles and actions (the call is not expected to spin, or 
> wait, it's the caller that is doing those things).
> 
> Given the natural way we'd describe what the options are for the receiver in 
> plain language, it became clear that Runtime fit better: we naturally say 
> "the runtime may..." and "indicate to the runtime...", not "the thread may" 
> or "indicate to the thread...". In addition, some of the implementation 
> possibilities (e.g. switch this thread to spin on a dedicated core) may 
> involve actions that are natural runtime actions but far outside of the scope 
> of what Thread might do.
> 
> With an event delivery paradigm ("I'm in a spin wait loop, you may want to do 
> something about that") Runtime.onSpinWait() fits common naming conventions 
> and roles. It's also  readable enough to understand that the Runtime is being 
> told that a spin wait is going on. And in that sense, it is just as 
> expressive as spinLoopHint(), while actually following a naming convention. 
> We left the "try to improve the performance" to the spec/JavaDoc because it 
> was very hard to fit in the name.

From Martin Thompson, on Tue, Dec 1, 2015 at 9:13 AM:
> ...
> The "on" prefix was suggested as the caller is notifying the runtime that it 
> is in a spin-wait loop. This allows the runtime the option of reacting to the 
> event, or not, and allows flexibility in how it chooses to react to this 
> information. The method is not waiting; the method is notifying that the 
> caller is waiting.
> 
> Yes, but we don't have Runtime.onGC() or Runtime.onRunFinalization(), and 
> both of those are documented as "suggesting" the VM perform those actions.  
> spinLoopHint() sounded much better than what's proposed here, and carries the 
> suggestion/hint/optionality that's desired.  IMHO, onSpinWait() is the least 
> appealing options proposed thus far.
> 
> System.gc() and Runtime.runFinalizersOnExit(boolean) are clear instructions 
> to the system/runtime to do something in an imperative fashion. The 
> onSpinWait() is a declarative statement about the state of the current 
> thread. I can understand a dislike to a name. We all have personal taste on 
> this but I don't think you are comparing similar semantics.
> 
> Consider the runtime as an object. You send it a message via a method. What 
> exactly is spinLoopHint() telling the Runtime what to do? It is applying an 
> event but not expressing it via any convention. "spinLoopHint()" works for me 
> on a Thread to an extent. We should express intent or declare status for 
> this. Hints don't fit comfortably in a programming model.
> 
> The actual naming does not matter so much as this will only be used by 
> minority of programmers. I'll prepare to be flamed on that :-) However it is 
> desperately needed and anything that makes it slip the date to make Java 9 
> would be such a let down.



Some discussion about naming choices, aiming the API at the target user, and 
what we expect people might do across platforms:

From Gil Tene, on Tue, Dec 1, 2015 at 4:35 PM:
> …
> On Dec 1, 2015, at 8:02 AM, Vitaly Davidovich  wrote:
> 
>> See my earlier suggestion about keeping target user of this API in mind and 
>> the level of this API (i.e. low).
> 
> In this sense (limited target audience that is very 

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

[Vitaly Davidovich]

So it still hasn't grown on me Gil! :) In particular, placing the method on
Runtime just doesn't make sense to me, even with the "we're notifying the
runtime we're spinning" sentiment.  If that's the "bar" for putting things
on Runtime, then a lot more things could (would) go in there; Thread.yield
--> informing runtime I'd like to yield, Thread.sleep --> informing runtime
I'd like to sleep, LockSupport:park --> informing runtime I'd like to park,
and so on.  The things that make sense on runtime are invoking GC and
finalization, which are truly runtime services.  This here is not a runtime
service.  IMO.

But, I'm more interested in the functionality -- you can place it on
ArrayList for all I care at that point :).

On Thu, Jan 28, 2016 at 12:25 PM, Gil Tene  wrote:

> 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:
>
> On the reasoning for moving from Thread.SpinLoopHint to Runtime.onSpinWait:
>
> From Gil Tene, on Tue, Dec 1, 2015 at 3:45 PM
> > …
> > Thread.spinLoopHint() was my first choice as well. But I was swayed by
> strong arguments against "hint" in the method name. Including the lack of
> "action" and ambiguity about roles. We looked at various names that were
> either clear and way too long or way too short or implementation specific
> (or narrowing), like skip, pause, relax, etc.
> >
> > Given the spec we agreed on, the name we were looking for was something
> that would be equivalent to the obvious expectations from something named
> as elaborately as:
> >
> >
> maybeYouShouldTryToImproveThePerformanceOfTheSpinWaitLoopMakingThisCall(),
> with the receiver being either the thread or the runtime.
> >
> > The "maybe you should try" part is important because doing nothing is a
> valid option, and accidentally failing to achieve the goal is probably ok,
> but consistently working in the opposite direction of the goal would be
> "surprising behavior". The "...making this call" part is important because
> of ambiguities around roles and actions (the call is not expected to spin,
> or wait, it's the caller that is doing those things).
> >
> > Given the natural way we'd describe what the options are for the
> receiver in plain language, it became clear that Runtime fit better: we
> naturally say "the runtime may..." and "indicate to the runtime...", not
> "the thread may" or "indicate to the thread...". In addition, some of the
> implementation possibilities (e.g. switch this thread to spin on a
> dedicated core) may involve actions that are natural runtime actions but
> far outside of the scope of what Thread might do.
> >
> > With an event delivery paradigm ("I'm in a spin wait loop, you may want
> to do something about that") Runtime.onSpinWait() fits common naming
> conventions and roles. It's also  readable enough to understand that the
> Runtime is being told that a spin wait is going on. And in that sense, it
> is just as expressive as spinLoopHint(), while actually following a naming
> convention. We left the "try to improve the performance" to the
> spec/JavaDoc because it was very hard to fit in the name.
>
> From Martin Thompson, on Tue, Dec 1, 2015 at 9:13 AM:
> > ...
> > The "on" prefix was suggested as the caller is notifying the runtime
> that it is in a spin-wait loop. This allows the runtime the option of
> reacting to the event, or not, and allows flexibility in how it chooses to
> react to this information. The method is not waiting; the method is
> notifying that the caller is waiting.
> >
> > Yes, but we don't have Runtime.onGC() or Runtime.onRunFinalization(),
> and both of those are documented as "suggesting" the VM perform those
> actions.  spinLoopHint() sounded much better than what's proposed here, and
> carries the suggestion/hint/optionality that's desired.  IMHO, onSpinWait()
> is the least appealing options proposed thus far.
> >
> > System.gc() and Runtime.runFinalizersOnExit(boolean) are clear
> instructions to the system/runtime to do something in an imperative
> fashion. The onSpinWait() is a declarative statement about the state of the
> current thread. I can understand a dislike to a name. We all have personal
> taste on this but I don't think you are comparing similar semantics.
> >
> > Consider the runtime as an object. You send it a message via a method.
> What exactly is spinLoopHint() telling the Runtime what to do? It is
> applying an event but not expressing it via any convention.
> "spinLoopHint()" works for me on a Thread to an 

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

[mark . reinhold]

2015/11/30 6:58 -0800, g...@azul.com:
> Update: After some significant back-and-forth between Doug and I on
> naming and JavaDoc'ing, and with Martin (Thompson) stepping in to
> help, we have what we think is a good spec and name selection for this
> thing. We're proposing to add a new static method to the Runtime
> class:
> 
> class Runtime { /...
> /**
>   * Method signifying that the caller is momentarily unable to
>   * progress until the occurrence of one or more actions of one or
>   * more other activities.  When invoked within each iteration, this
>   * method typically improves performance of spin wait loop
>   * constructions.
>   */
>  public static void onSpinWait() {};
> }

I'm glad to see some agreement here, but I'm puzzled by the proposal
to to place this in the Runtime class.  What's the reasoning for that?
Wouldn't this more naturally be placed in java.lang.Thread?

Also, I don't think this single method needs a JEP, but you're welcome
to do it that way if you really want to.

- Mark

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

[Viktor Klang]

While we are painting the bikeshed, what about `powerNap()`

On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich  wrote:

> Minor quibble, but why the "on" prefix in the name? Maybe just me, but
> onXYX is typically used for event notification style APIs.
>
> Also, the "wait" part seems inappropriate as the method itself isn't doing
> any waiting.  What was wrong with the original spinLoopHint name? Or
> cpuRelax()?
>
> sent from my phone
> On Nov 30, 2015 9:59 PM, "Gil Tene"  wrote:
>
>> Update: After some significant back-and-forth between Doug and I on
>> naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we
>> have what we think is a good spec and name selection for this thing. We're
>> proposing to add a new static method to the Runtime class:
>>
>> class Runtime { /...
>> /**
>>   * Method signifying that the caller is momentarily unable to
>>   * progress until the occurrence of one or more actions of one or
>>   * more other activities.  When invoked within each iteration, this
>>   * method typically improves performance of spin wait loop
>>   * constructions.
>>   */
>>  public static void onSpinWait() {};
>> }
>>
>> See updated details, including a link to the updated JEP draft, as well
>> as links to working prototype implementations, webrevs against OpenJDK9b94,
>> and example here:
>> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <
>> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All
>> names have changed to reflect the new naming (onSpinWait,
>> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
>>
>> As an interesting stat, the total changes in the WebRevs amount to 78
>> added lines (across 14 files) , and 0 lines removed or changed. Hopefully a
>> good indication of relatively low footprint and risk.
>>
>> — Gil.
>>
>>
>>
>>
>>
>>
> ___
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Cheers,
√

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

[Paul Sandoz]

> On 1 Dec 2015, at 03:58, Gil Tene  wrote:
> 
> Update: After some significant back-and-forth between Doug and I on naming 
> and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what 
> we think is a good spec and name selection for this thing. We're proposing to 
> add a new static method to the Runtime class:
> 
> class Runtime { /...
>/**
>  * Method signifying that the caller is momentarily unable to
>  * progress until the occurrence of one or more actions of one or
>  * more other activities.  When invoked within each iteration, this
>  * method typically improves performance of spin wait loop
>  * constructions.
>  */
> public static void onSpinWait() {};
> }
> 

Short and sweet. I like it. I think it would be useful to add an @apiNote with 
explanatory text similar to that in the motivation section of the JEP.

If you like I can help guide this through the JEP process.


> See updated details, including a link to the updated JEP draft, as well as 
> links to working prototype implementations, webrevs against OpenJDK9b94, and 
> example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest 
>  . All names 
> have changed to reflect the new naming (onSpinWait, 
> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
> 
> As an interesting stat, the total changes in the WebRevs amount to 78 added 
> lines (across 14 files) , and 0 lines removed or changed. Hopefully a good 
> indication of relatively low footprint and risk.
> 

I agree, the JDK and hotspot patches (for x86 support) are quite small.

Paul.

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

[Vitaly Davidovich]

Minor quibble, but why the "on" prefix in the name? Maybe just me, but
onXYX is typically used for event notification style APIs.

Also, the "wait" part seems inappropriate as the method itself isn't doing
any waiting.  What was wrong with the original spinLoopHint name? Or
cpuRelax()?

sent from my phone
On Nov 30, 2015 9:59 PM, "Gil Tene"  wrote:

> Update: After some significant back-and-forth between Doug and I on naming
> and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have
> what we think is a good spec and name selection for this thing. We're
> proposing to add a new static method to the Runtime class:
>
> class Runtime { /...
> /**
>   * Method signifying that the caller is momentarily unable to
>   * progress until the occurrence of one or more actions of one or
>   * more other activities.  When invoked within each iteration, this
>   * method typically improves performance of spin wait loop
>   * constructions.
>   */
>  public static void onSpinWait() {};
> }
>
> See updated details, including a link to the updated JEP draft, as well as
> links to working prototype implementations, webrevs against OpenJDK9b94,
> and example here:
> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <
> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All
> names have changed to reflect the new naming (onSpinWait,
> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
>
> As an interesting stat, the total changes in the WebRevs amount to 78
> added lines (across 14 files) , and 0 lines removed or changed. Hopefully a
> good indication of relatively low footprint and risk.
>
> — Gil.
>
>
>
>
>
>

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

[Doug Lea]

On 12/01/2015 05:36 AM, Paul Sandoz wrote:



On 1 Dec 2015, at 03:58, Gil Tene  wrote:

class Runtime { /...
/**
  * Method signifying that the caller is momentarily unable to
  * progress until the occurrence of one or more actions of one or
  * more other activities.  When invoked within each iteration, this
  * method typically improves performance of spin wait loop
  * constructions.
  */
 public static void onSpinWait() {};
}



Short and sweet. I like it. I think it would be useful to add an @apiNote with 
explanatory text similar to that in the motivation section of the JEP.




Or maybe not. Recent experience suggests that it is hard to add a brief
explanatory note or usage guidance without saying something
confusing or wrong wrt usages focussing on latency, throughput,
or power -- these effects may vary across processors with
different instructions (possibly just no-op) used to implement it.
Not a lot, but this accounts for the bland wording of
"typically improves performance".

-Doug

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

[Gil Tene]

Update: After some significant back-and-forth between Doug and I on naming and 
JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we 
think is a good spec and name selection for this thing. We're proposing to add 
a new static method to the Runtime class:

class Runtime { /...
/**
  * Method signifying that the caller is momentarily unable to
  * progress until the occurrence of one or more actions of one or
  * more other activities.  When invoked within each iteration, this
  * method typically improves performance of spin wait loop
  * constructions.
  */
 public static void onSpinWait() {};
}

See updated details, including a link to the updated JEP draft, as well as 
links to working prototype implementations, webrevs against OpenJDK9b94, and 
example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest 
 . All names 
have changed to reflect the new naming (onSpinWait, 
-XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).

As an interesting stat, the total changes in the WebRevs amount to 78 added 
lines (across 14 files) , and 0 lines removed or changed. Hopefully a good 
indication of relatively low footprint and risk.

— Gil.

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

[Gil Tene]

[Sorry for the 4 day delay in response. JavaOne sort of got in the way]

I think we are looking at two separate and almost opposite motivations, each of 
which is potentially independently valid. Each can be characterized by 
answering the question: "How does adding this to an empty while(!ready) {} spin 
loop change things?".

Putting name selection aside, one motivation can be characterized with "if I 
add this to a spinning loop, keep spinning hard and don't relinquish resources 
any more than the empty loop would, but try to leave the spin as fast as 
possible. And it would be nice if power was conserved as a side effect.". The 
other motivation can be characterized with "If I add this to a spin loop, I am 
indicating that I can't make useful progress unless stuff happens or some 
internal time limit is reached, and that it is ok to try and make better use of 
resources (including my CPU), relinquishing them more aggressively than the 
empty loop would. And it would be nice if reaction time was faster most of the 
time too". 

The two motivations are diametrically opposed in their expected effect when 
compared to the behavior of an empty spin loop that does not contain them. Both 
can be validly implemented as a nop, but they "hint" in opposite directions. 
The former is what I have been calling a spin loop hint (in the "keep spinning 
and don't let go" sense), and the latter is a "spin/yield" (in the "ok to let 
go" sense). They have different uses.

> On Oct 24, 2015, at 11:09 AM, Doug Lea  wrote:
> 
> 
> Here's one more attempt to explain why it would be a good idea
> to place, name, and specify this method in a way that is more
> general than "call this method only if you want a PAUSE instruction
> on a dedicated multicore x86":

I agree with the goal of not aiming at a processor specific behavior, and 
focusing on documenting intent and expectation. But I think that the intent 
suggested in the spinLoopHint() JavaDoc does that. As noted later in this 
e-mail, there are other things that the JVM can choose to do to work in the 
hint's intended direction.

> 
> On 10/15/2015 01:23 PM, Gil Tene wrote:
> ...
>> 
>> As noted in my proposed JavaDoc, I see the primary indication of the hint to
>> be that the reaction time to events that would cause the loop to exit (e.g.
>> in nanosecond units) is more important to the caller than the speed at which
>> the loop is executing (e.g. in "number of loop iterations per second" units).
> 
> Sure. This can also be stated:
> 
> class Thread { ...
> /**
>  * 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 (or that its containing loop is
>  * otherwise terminated).  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.  A
>  * spin-loop that invokes this method on each iteration is likely to
>  * be more responsive than it would otherwise be.
>  */
>  public static void spinYield();
> }

I like the "more responsive than it would otherwise be" part. That certainly 
describes how this is different than an empty loop. But the choice of "mainly 
applicable" in spinYield() is exactly opposite from the main use case 
spinLoopHint() is intended for (which is somewhere between "indefinite 
spinning" and "I don't care what kind of spinning"). This JavaDoc looks like a 
good description of spinYield() and it's intended main use cases, but this 
stated intent and expectations (when compared to just doing an empty spin loop) 
works in the opposite direction of what spinLoopHint's intent and expectations 
need to be for it's common use cases.

> 
>> Anyone running indefinite spin loops on a uniprocessor deserves whatever they
>> get. Yielding in order to help them out is not mercy. Let Darwin take care of
>> them instead.
>> 
>> But indefinite user-mode spinning on many-core systems is a valid and common
>> use case (see the disruptor link in my previous e-mail).
> 
>> In such situations the spinning loop should just be calling yield(), or
>> looping for a very short count (like your magic 64) and then yielding. A
>> "magically choose for me whether reaction time or throughput or being nice to
>> others is more important" call is not a useful hint IMO.
>> 
>> Like in my uniprocessor comment above, any program spinning indefinitely (or
>> for a non-trivial amount of time) with load > # cpus deserves what it gets.
> 
> The main problem here is that there are no APIs reporting whether
> load > # cpus, and no good prospects for them either, especially
> considering the use of hypervisors (that may intentionally mis-report)
> and tightly packed cloud nodes where the number of cpus currently
> available to a program may depend on random transient effects of
> co-placement 

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

[Doug Lea]

Here's one more attempt to explain why it would be a good idea
to place, name, and specify this method in a way that is more
general than "call this method only if you want a PAUSE instruction
on a dedicated multicore x86":

On 10/15/2015 01:23 PM, Gil Tene wrote:


I also don't think that the "…momentarily unable to progress until the
occurrence of one or more actions of one or more other threads. " is true:
while (!(done || (count++ > threshold))) { spinLoopHint(); } can progress
without any action by any other thread.


OK, this needs better wording to rule out silly interpretations
about loop bounds. See below.



As noted in my proposed JavaDoc, I see the primary indication of the hint to
be that the reaction time to events that would cause the loop to exit (e.g.
in nanosecond units) is more important to the caller than the speed at which
the loop is executing (e.g. in "number of loop iterations per second" units).


Sure. This can also be stated:

class Thread { ...
 /**
  * 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 (or that its containing loop is
  * otherwise terminated).  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.  A
  * spin-loop that invokes this method on each iteration is likely to
  * be more responsive than it would otherwise be.
  */
  public static void spinYield();
}


Anyone running indefinite spin loops on a uniprocessor deserves whatever they
get. Yielding in order to help them out is not mercy. Let Darwin take care of
them instead.

But indefinite user-mode spinning on many-core systems is a valid and common
use case (see the disruptor link in my previous e-mail).



In such situations the spinning loop should just be calling yield(), or
looping for a very short count (like your magic 64) and then yielding. A
"magically choose for me whether reaction time or throughput or being nice to
others is more important" call is not a useful hint IMO.

Like in my uniprocessor comment above, any program spinning indefinitely (or
for a non-trivial amount of time) with load > # cpus deserves what it gets.


The main problem here is that there are no APIs reporting whether
load > # cpus, and no good prospects for them either, especially
considering the use of hypervisors (that may intentionally mis-report)
and tightly packed cloud nodes where the number of cpus currently
available to a program may depend on random transient effects of
co-placement with other services running on that node.

And given that programmers cannot portably comply, the method must
allow implementations that take the best course of action known to the JVM.

Despite all of the above, I agree that an OK initial hotspot implementation
is just to emit PAUSE if on x86 else no-op. It might be worth then
experimenting with randomized branching etc on other platforms, and
someday further exploring some cheap form of load detection, perhaps
kicking in only upon repeated invocation.

-Doug

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

[Gil Tene]

> On Oct 15, 2015, at 11:32 PM, Doug Lea  wrote:
> 
> 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();

I don't think that this is a good description of the use cases. Yes, the hint 
is helpful for spin-then-block constructions, but that's just a part of where 
it can help. In fact, I expect the hint to be very applicable for 
indefinitely-spinning loops, and I expect the measurable impact there to be 
much more reliably noticed because such loops are invariably concerned with 
fast reaction times above all else.

I also don't think that the "…momentarily unable to progress until the 
occurrence of one or more actions of one or more other threads. " is true: 
while (!(done || (count++ > threshold))) { spinLoopHint(); } can progress 
without any action by any other thread.

As noted in my proposed JavaDoc, I see the primary indication of the hint to be 
that the reaction time to events that would cause the loop to exit (e.g. in 
nanosecond units) is more important to the caller than the speed at which the 
loop is executing (e.g. in "number of loop iterations per second" units). So if 
we are focusing on the spec, here is my suggested (edited to be more specific
) spec:

/**
* Provide the JVM with a hint that this call is made from within a spinning
* loop. The JVM may assume that the reaction time to events that would
* cause the loop to terminate is more important than the speed of executing
* the loop (e.g. in terms of number of loop iterations per second).
* Power savings may also occur, but those are considered incidental to the 
* primary purpose of improving reaction time. The JVM will not slow down
* the loop execution to a point where execution will be delayed indefinitely,
* but other choices of loop execution speed are system-specific. Note that a
* nop is a valid implementation of this hint.
*/

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

Anyone running indefinite spin loops on a uniprocessor deserves whatever they 
get. Yielding in order to help them out is not mercy. Let Darwin take care of 
them instead.

But indefinite user-mode spinning on many-core systems is a valid and common 
use case (see the disruptor link in my previous e-mail). And because a spin 
loop hint is extremely useful for indefinitely spinning loop situations, and a 
spin hint is primarily intended to improve the reaction time of spin loops, I 
would describe any explicit yielding by the JVM at the hint point as 
mis-behavior. [Not quite an invalid behavior, because we don't want to specify 
allowed behavior too strongly, but certainly surprising, unexpected, and highly 
disappointing given the intent expressed by the hint]. Yes, the OS or 
hypervisor may choose to preempt a thread at any random point in code, 
including at these hint points, but that's their job and their problem, and not 
the JVM's. The JVM should not be in the business of voluntarily and implicitly 
yielding at specific points in code, and especially not at points in code that 
spins and hints that it wants to improve the performance of that spin.

If what you want is a spin loop that yields, write one: while (!done) {  
yield(); }. I don't see how while (!done) { spinYield(); } has any different 
meaning to the reader. It just reads as something like "yield faster, knowing 
that you are in a spin".

> Also, I believe that some x86
> hypervisors intercept PAUSE and do something roughly similar
> after repeated invocations.

As to hypervisor choices: preempting a guest OS at a PAUSE instruction is 
actually higher risk, since the PAUSE instruction could be taken while holding 
a ciritical kernel resource (e.g. mremap always grabs one spinlock while 
holding another spinlock). The trick most hypervisors seem to use is to prefer 
to preempt code in user mode rather than in kernel mode, since user mode code 
doesn't see preemption as an invalid operation, but kernel 

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

[Doug Lea]

Some notes after reading follow-ups.

One question is whether there should be a method that clues in
the JVM about what change is being waited for. This is the territory of
monitor-like constructions (see below), as opposed to the
yield/sleep-like constructions that Gil was initially proposing.

For these, the next question is whether this should be more
like Thread.yield() vs Thread.sleep(). If it could be like
sleep, then new a API might not be needed: JVMs could
implement sleep(0, 1) (or any small value of nanosec arg)
using a PAUSE instruction on platforms supporting them.
But sleep is also required to check interrupt status,
which means that at least one extra load would be needed
in addition to PAUSE. So it seems that something yield-like
(with no obligation to check interrupt) is still desirable,
leading either to my original suggestion:

  /**
   * A hint to the platform that the current thread is momentarily
   * unable to progress...
   */
  public static void spinYield();

OR something more analogous to sleep, but without interrupt check:

 /**
  * A hint to the platform that the current thread is unlikely
  * to progress for the indicated duration in nanoseconds...
  */
  public static void yield(long nanoSeconds);

When available, JVMs would implement small values via PAUSE,
larger by calling plain yield(), but in no case promising to
return in either at least or at most the given duration.
While it is a little odd, it seems to cover John Rose's desire
to force an argument dependency.

I think either of these would be OK.

We'd use this functionality in a few places inside java.util.concurrent.
We can't do so as aggressively as some users might like: we
generally bound spin-then-block constructions to an approximation
of best-case unavailability (lock-hold etc) times, so as to
work OK when systems are heavily loaded. When we have done more
than this, we have gotten justifiable complaints. But we also
have "try" and "poll" forms of almost everything so users can
add additional spins themselves. Or create custom sync using
base capabilities.

Back to the question of monitor-like constructions:

Low-level memory-wait instructions are limited in what they
can wait for -- basically only changes at fixed addresses.
This is not an easy fit for GCed languages where the address
of a variable might change. However, there is at least one
case where this can work: park/unpark are (and are nearly forced
to be) implemented using an underlying native-level semaphore.
So it should be possible to at least sometimes use MWAIT
inside park to reduce unproductive context switches.
The "sometimes" part might vary across platforms.
In particular, the implementation of LockSupport.parkNanos
could always just invoke an MWAIT-based intrinsic for small
arguments. It would be great if people working on hotspot
explored such options.

So for this particular application of MWAIT-like support
(which should be vastly more common than other uses anyway),
we could side-step for now analogs of proposed C++ "synchronics"
and the like that would require unknown mechanics on
still-unreleased VarHandles.

-Doug

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

[Gil Tene]

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.

On the name choice: things that include the word "yield" vs. spinLoopHint()::

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: spinLoopHint is 
motivated by wanting to spin while holding onto the CPU (intentionally not 
yielding to other processes), and by the wish to improve performance while 
doing so, primarily by reducing the reaction time to a loop-terminating event. 
So spinLoopHint() is something that very selfish spinning code does without 
reducing it's selfishness. In contrast, yield() is virtually always done as an 
unselfish act (the very word suggests it). The general expectation with yield() 
calls is that that the OS scheduler can make use of the core for other uses, it 
is OK to switch away form the current task since the thread may not be making 
progress, or may be ok with relinquishing resources to be "nice" to others". As 
such, a yield() generally suggests a system call, a (relatively) large 
overhead, and a willingness to sacrifice reaction time in order to allow others 
to make use of the CPU.

My preferred choice of the spinLoopHint() name comes directly from how the 
behavior expectations of of a PAUSE-like instruction are already expressed in 
relevant documents. E.g. Intel's documentation describes PAUSE instructions as 
a "Spin Loop Hint".

On the no-args vs. "with some arg" variants:

With regards to passing a time value (e.g. the yield(long nanoseconds) example 
in your e-mail below): A spinLoopHint() is a natural fit for loops that already 
do their own spinning, and as such needs to allow those loop to deal with their 
own composition, choices around termination conditions, state updates, and 
choices about backing of or employing time or count based termination 
behaviors. Choosing and dictating a specific mechanism (nanoseconds) or 
terminating condition checks will interfere with the compostability of 
spinLoopHint() into such code. To use a specific example: E.g. the yield(long 
nanoSeconds) form (even if it's called spinLoopHint(long nanoSeconds)) would 
not be directly usable in the following code:

while (!(doneCond1 || doneCond2 || count++ > backOffThreshld) {
spinLoopHint():
}

Similarly, a no-args spinLoopHint() will cleanly drop into things like the 
disruptor's bust spin waitFor() variant 
(https://github.com/LMAX-Exchange/disruptor/blob/f29b3148c2eef3aa2dc5d5f570d7dde92b2f98ba/src/main/java/com/lmax/disruptor/BusySpinWaitStrategy.java#L28),
 but something that takes a nanoseconds argument would not.

I think that compose-abiliy should be our main driver here. Java code already 
knows how to spin in many interesting ways. It just needs to have away to hint 
that reaction time is more important that speed in the spin, and that's what 
I'm suggesting as the main purpose of a spinLoophint(). See proposed JavaDoc 
below.

— Gil.

/**
 * Provide the JVM with a hint that this call is made from within a spinning
 * loop. The JVM may assume that the speed of executing the loop (e.g. in
 * terms of number of loop executions per second) is less important than the
 * reaction time to events that would cause the loop to terminate, or than
 * potential power savings that may be derived from possible execution
 * choices. The JVM will not slow down the loop execution to a point where
 * execution will be delayed indefinitely, but other choices of loop execution
 * speed are system-specific. Note that a nop is a valid implementation of
 * this hint.
 */
public static void spinLoopHint() {
}


> On Oct 14, 2015, at 11:04 PM, Doug Lea  wrote:
> 
> Some notes after reading follow-ups.
> 
> One question is whether there should be a method that clues in
> the JVM about what change is being waited for. This is the territory of
> monitor-like constructions (see below), as opposed to the
> yield/sleep-like constructions that Gil was initially proposing.
> 
> For these, the next question is whether this should be more
> like Thread.yield() vs Thread.sleep(). If it could be like
> sleep, then new a API might not be needed: JVMs could
> implement sleep(0, 1) (or any small value of nanosec arg)
> using a PAUSE instruction on platforms supporting them.
> But sleep is also required to check interrupt status,
> which means that at least one extra load would be needed
> in addition to PAUSE. So it seems that something yield-like
> (with no obligation to check interrupt) is still desirable,
> leading either to my original suggestion:
> 
>  /**
>   * A hint to the platform that the current thread is momentarily
>   * unable to progress...
>   */
>  public static void spinYield();
> 
> OR something more analogous to sleep, but 

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

[Haim Yadid]

+1 as well :) 

BR, 
Haim Yadid


> On 8 באוק׳ 2015, at 17:56, Doug Lea  wrote:
> 
>> On 10/08/2015 07:01 AM, David M. Lloyd wrote:
>>> On 10/08/2015 05:58 AM, Doug Lea wrote:
>>> 
>>> class Thread { //
>>>   /**
>>>* A hint to the platform that the current thread is momentarily
>>>* unable to progress. ... add more guidance ...
>>>*/
>>>   void spinYield();
> 
> should be:
>  public static 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.
>> 
>> If the method is static, then the impact of a clashing name should be fairly
>> minimal.
> 
> Right. For statics, pretty much the only concern is whether
> reflective mechanics (Class.getMethod etc) return unexpected
> entries that would break existing code. The name "spinYield"
> seems unlikely enough to be a problem though.
> 
> -Doug
> 
> 
> ___
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

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

[Viktor Klang]

+1

On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz  wrote:

>
> > On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote:
> >
> > 2015/10/8 7:56 -0700, d...@cs.oswego.edu:
>  ...
> 
>  class Thread { //
> /**
>  * A hint to the platform that the current thread is momentarily
>  * unable to progress. ... add more guidance ...
>  */
>  void spinYield();
> >>
> >> should be:
> >>   public static void spinYield();
> >
> > Yes -- let's keep this simple.  It's just one method, another hint
> > in j.l.Thread which can be ignored (or not) by the VM.
> >
> > This concept seems sufficiently well understood, based on its use
> > in other platforms, that putting it directly into j.l.Thread is not
> > a huge risk.  I don't see a strong need for this to start out as a
> > JDK-specific API.
> >
>
> +1
>
> Paul.
>
> ___
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Cheers,
√

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

[Jean Philippe Bempel]

On Thu, Oct 8, 2015 at 1:01 PM, David M. Lloyd 
wrote:

>
> If the method is static, then the impact of a clashing name should be
> fairly minimal.
>
>
+1 on this, I do not see the benefit of an instance method either here. But
good idea, Doug, for Thread class and the yield hint :)

-- 
*The information contained in or attached to this email is strictly 
confidential. If you are not the intended recipient, please notify us 
immediately by telephone and return the message to us.*

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

[mark . reinhold]

2015/10/8 7:56 -0700, d...@cs.oswego.edu:
>>> ...
>>> 
>>> class Thread { //
>>> /**
>>>  * A hint to the platform that the current thread is momentarily
>>>  * unable to progress. ... add more guidance ...
>>>  */
>>>  void spinYield();
> 
> should be:
>public static void spinYield();

Yes -- let's keep this simple.  It's just one method, another hint
in j.l.Thread which can be ignored (or not) by the VM.

This concept seems sufficiently well understood, based on its use
in other platforms, that putting it directly into j.l.Thread is not
a huge risk.  I don't see a strong need for this to start out as a
JDK-specific API.

- Mark

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

[Paul Sandoz]

> On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote:
> 
> 2015/10/8 7:56 -0700, d...@cs.oswego.edu:
 ...
 
 class Thread { //
/**
 * A hint to the platform that the current thread is momentarily
 * unable to progress. ... add more guidance ...
 */
 void spinYield();
>> 
>> should be:
>>   public static void spinYield();
> 
> Yes -- let's keep this simple.  It's just one method, another hint
> in j.l.Thread which can be ignored (or not) by the VM.
> 
> This concept seems sufficiently well understood, based on its use
> in other platforms, that putting it directly into j.l.Thread is not
> a huge risk.  I don't see a strong need for this to start out as a
> JDK-specific API.
> 

+1

Paul.