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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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;

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

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

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

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

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

> 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

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

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

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

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

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

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 {

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

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

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

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

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

> 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

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

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.

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

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

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

+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

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

+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

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

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

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

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

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

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