Re: Spin Loop Hint support: Draft JEP

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Martin Thompson-2

Date: Tue, 1 Dec 2015 07:16:24 -0500
From: Vitaly Davidovich <[hidden email]>
        <[hidden email]>, [hidden email]
Subject: 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()?

Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

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.
 

On Tue, Dec 1, 2015 at 8:17 AM, Martin Thompson <[hidden email]> wrote:

Date: Tue, 1 Dec 2015 07:16:24 -0500
From: Vitaly Davidovich <[hidden email]>
        <[hidden email]>, [hidden email]
Subject: 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()?

Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Martin Thompson-2

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

But relax, although a common term for this scenario, is still vague enough as to not indicate exactly how it does this, so I don't see any leakage of implementation details.  Moreover, the niche target users of this API are likely going to know exactly what they want at the machine instruction level on the platform(s) they care about.  This isn't some widely applicable general purpose API -- it's a low level API, and low level APIs should not be intentionally vague.  I'm almost certain that 99% of people using this API will know, either ahead of time or by researching, exactly what happens under the hood.  When trying to control things at this level, implementation details start to matter.

As for optionality, yes, you may want to convey that.  But I don't think it necessarily has to be in the name - javadoc is more than sufficient.  Again, let's keep in mind target audience.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 
Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"

The 2nd sentence of Runtime.gc() javadoc begins with (emphasis mine) "Calling this method suggests that the Java virtual machine expend effort ...".  We all know that there's ways to disable explicit GC from doing anything at all, so although the name isn't Runtime.maybeGC() or Runtime.gcHint() or whatever, anyone exploring this (also somewhat niche, relatively speaking) API will quickly learn that it doesn't guarantee anything.

I'll just reiterate that I think target audience of this API should be kept in mind; it's low level functionality and there's no need to try and obfuscate it.
 

On Tue, Dec 1, 2015 at 10:15 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <[hidden email]> wrote:

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

"Relaxing" the CPU is one specific possibility for what the JVM might want to do to improve the performance and responsiveness of a spin wait loop. E.g. The JVM might achieve the desired improvement by doing other things in conjunction with, or in place of relaxing the CPU. Such as affecting scheduling priority or affinity, or doing some other thing that might reduce the likelihood of yielding the CPU. In addition , depending on platform, relaxing the CPU may be the wing thing to do: i.e. Some of the CPU-relaxing options on some platforms dramatically reduce the performance of a spin wait loops and increase their reaction time (rather than improve and reduce).

I wanted the name to suggest intent without dictating implementation, and for the spec to make it clear that improving the performance of a spin wait loop construct is the intended (or hoped for) result without committing to actually achieving that. The runtime may choose to ignore the indication, but it would be surprising for it to make things "worse" for the calling spin wait loop compared to code that doesn't make the same call.


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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 

Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"


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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
In reply to this post by Vitaly Davidovich
See my earlier suggestion about keeping target user of this API in mind and the level of this API (i.e. low).

As for doing nothing in the implementation, OK.  But I bet if someone using this API finds out it does nothing on their platform they're going to stop using this API and go back to manual hacks that have at least some chance of achieving desired results.  So while I understand the general motivation of not leaking implementation details, I don't agree this API is the appropriate place for that.

On Tue, Dec 1, 2015 at 10:45 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <[hidden email]> wrote:

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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


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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
In reply to this post by Vitaly Davidovich
I suggested relax because it's a commonly used name for this effect.  With no prior art in this area, I'd agree that relax can be misinterpreted.  But I'm just as happy with your original spinLoopHint on the Thread class, to be honest.  I just don't like onSpinWait() on the Runtime class.

On Tue, Dec 1, 2015 at 11:19 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 7:32 AM, Vitaly Davidovich <[hidden email]> wrote:

On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

But relax, although a common term for this scenario, is still vague enough as to not indicate exactly how it does this, so I don't see any leakage of implementation details.  Moreover, the niche target users of this API are likely going to know exactly what they want at the machine instruction level on the platform(s) they care about.  This isn't some widely applicable general purpose API -- it's a low level API, and low level APIs should not be intentionally vague.  I'm almost certain that 99% of people using this API will know, either ahead of time or by researching, exactly what happens under the hood.  When trying to control things at this level, implementation details start to matter.

The goal of the call is not to relax the CPU. It is to improve the performance of the spin loop.

This makes goal the opposite of what "relax" suggests. While the spec rules (and clearly says that performance improvement is the goal), we'd probably agree that names like "chill()", "slowDown()", or "dontBotherWithSpeed()" would be a bad fit. "Relax" fits right in with those...

The fact that the performance-enhancing goal can actually be technically achieved in some specific CPUs by relaxing their execution in specific ways is surprising in itself. It makes for interesting conversation ("wow, who knew that relaxing the aggressiveness of speculation might actually make the reaction time faster?"), but the fact that it's interesting and surprising is a good indication that it is a bad name choice.

There are various ways to relax CPUs that are wrong to use for the goal of the call, but would be natural for something called "relax". These include deeper cstates in x86, variations of MWAIT with short timeouts on various CPUs, and even instructions named "pause" on some platforms that consistently hurt performance but help save power. These make it clear that if we used "relax" as a name in this spin wait loop performance context, we actually mean "relaxInA2015x86PauseInstructionSense()"...


As for optionality, yes, you may want to convey that.  But I don't think it necessarily has to be in the name - javadoc is more than sufficient.  Again, let's keep in mind target audience.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 
Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"

The 2nd sentence of Runtime.gc() javadoc begins with (emphasis mine) "Calling this method suggests that the Java virtual machine expend effort ...".  We all know that there's ways to disable explicit GC from doing anything at all, so although the name isn't Runtime.maybeGC() or Runtime.gcHint() or whatever, anyone exploring this (also somewhat niche, relatively speaking) API will quickly learn that it doesn't guarantee anything.

I'll just reiterate that I think target audience of this API should be kept in mind; it's low level functionality and there's no need to try and obfuscate it.
 

On Tue, Dec 1, 2015 at 10:15 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <[hidden email]> wrote:

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

"Relaxing" the CPU is one specific possibility for what the JVM might want to do to improve the performance and responsiveness of a spin wait loop. E.g. The JVM might achieve the desired improvement by doing other things in conjunction with, or in place of relaxing the CPU. Such as affecting scheduling priority or affinity, or doing some other thing that might reduce the likelihood of yielding the CPU. In addition , depending on platform, relaxing the CPU may be the wing thing to do: i.e. Some of the CPU-relaxing options on some platforms dramatically reduce the performance of a spin wait loops and increase their reaction time (rather than improve and reduce).

I wanted the name to suggest intent without dictating implementation, and for the spec to make it clear that improving the performance of a spin wait loop construct is the intended (or hoped for) result without committing to actually achieving that. The runtime may choose to ignore the indication, but it would be surprising for it to make things "worse" for the calling spin wait loop compared to code that doesn't make the same call.


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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 

Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"


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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
In reply to this post by Vitaly Davidovich
Ok, carry on then :) Thanks for working on this, by the way -- I don't mean to let the naming debate imply otherwise.

On Tue, Dec 1, 2015 at 11:35 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 8:02 AM, Vitaly Davidovich <[hidden email]> 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 technical) Thread.foobar(), Thread.spinLoopHint(), Thread.relax(), and Runtime.onSpinWait() are all equivalent.

The naming debate is mostly driven by longer term thinking, wanting to avoid unforeseen consequences, and s wish for readability. Which are the things that seem to drive most naming debates and make naming one of those hard things to do in CS.

Given that it's already cost a month of elapsed time, I'd like to try to push forward with what we ended up with.

As for doing nothing in the implementation, OK.  But I bet if someone using this API finds out it does nothing on their platform they're going to stop using this API and go back to manual hacks that have at least some chance of achieving desired results.  So while I understand the general motivation of not leaking implementation details, I don't agree this API is the appropriate place for that.

The main driver for this JEP is the fact that in Java today, there are no good manual hack options, and on platforms that do support enhanced-performance spinning, spin wait loops written in Java remain inferior (in performance and reaction time) to ones written in other languages.

I expect spin-loop writers to naturally use Runtime.onSpinWait() across platforms, accepting that it may do nothing on some (e.g. On platforms where no HW support for better spinning performance exists) and improve spinning performance on others. E.g. I fully expect the various disruptor waitFor() variants will still exist, but half of them will probably end up using Runtime.onSpinWait() for enhanced performance, and would do nothing different (in their Java code) for x86, Aarch64, Aarch32, Power, SPARC, or MIPS.


On Tue, Dec 1, 2015 at 10:45 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <[hidden email]> wrote:

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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


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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP

Vitaly Davidovich
In reply to this post by Vitaly Davidovich
But can you live with it? Trust me, it grows on you... ;-). Especially when you end up defending it in an e-mail thread.

I can live with just about anything :).  I care more about the functionality than the naming (despite what this thread may lead you to believe), but I doubt it'll grow on me :).

On Tue, Dec 1, 2015 at 11:38 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 8:29 AM, Vitaly Davidovich <[hidden email]> wrote:

I suggested relax because it's a commonly used name for this effect.  With no prior art in this area, I'd agree that relax can be misinterpreted.  But I'm just as happy with your original spinLoopHint on the Thread class, to be honest.

I liked it too. But was willing to give up on it given the strong arguments and opinions against it, and in the interest of getting something acceptable done.

I just don't like onSpinWait() on the Runtime class.

But can you live with it? Trust me, it grows on you... ;-). Especially when you end up defending it in an e-mail thread.



On Tue, Dec 1, 2015 at 11:19 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 7:32 AM, Vitaly Davidovich <[hidden email]> wrote:

On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

But relax, although a common term for this scenario, is still vague enough as to not indicate exactly how it does this, so I don't see any leakage of implementation details.  Moreover, the niche target users of this API are likely going to know exactly what they want at the machine instruction level on the platform(s) they care about.  This isn't some widely applicable general purpose API -- it's a low level API, and low level APIs should not be intentionally vague.  I'm almost certain that 99% of people using this API will know, either ahead of time or by researching, exactly what happens under the hood.  When trying to control things at this level, implementation details start to matter.

The goal of the call is not to relax the CPU. It is to improve the performance of the spin loop.

This makes goal the opposite of what "relax" suggests. While the spec rules (and clearly says that performance improvement is the goal), we'd probably agree that names like "chill()", "slowDown()", or "dontBotherWithSpeed()" would be a bad fit. "Relax" fits right in with those...

The fact that the performance-enhancing goal can actually be technically achieved in some specific CPUs by relaxing their execution in specific ways is surprising in itself. It makes for interesting conversation ("wow, who knew that relaxing the aggressiveness of speculation might actually make the reaction time faster?"), but the fact that it's interesting and surprising is a good indication that it is a bad name choice.

There are various ways to relax CPUs that are wrong to use for the goal of the call, but would be natural for something called "relax". These include deeper cstates in x86, variations of MWAIT with short timeouts on various CPUs, and even instructions named "pause" on some platforms that consistently hurt performance but help save power. These make it clear that if we used "relax" as a name in this spin wait loop performance context, we actually mean "relaxInA2015x86PauseInstructionSense()"...


As for optionality, yes, you may want to convey that.  But I don't think it necessarily has to be in the name - javadoc is more than sufficient.  Again, let's keep in mind target audience.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 
Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"

The 2nd sentence of Runtime.gc() javadoc begins with (emphasis mine) "Calling this method suggests that the Java virtual machine expend effort ...".  We all know that there's ways to disable explicit GC from doing anything at all, so although the name isn't Runtime.maybeGC() or Runtime.gcHint() or whatever, anyone exploring this (also somewhat niche, relatively speaking) API will quickly learn that it doesn't guarantee anything.

I'll just reiterate that I think target audience of this API should be kept in mind; it's low level functionality and there's no need to try and obfuscate it.
 

On Tue, Dec 1, 2015 at 10:15 AM, Gil Tene <[hidden email]> wrote:


Sent from Gil's iPhone

On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <[hidden email]> wrote:

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.

Yes, that would work for me as well although I'd prefer to have 'cpu' in the name to be more clear.  But either way, sticking to known/common nomenclature is good; ad-hoc names are not.

On why "relax" (or other "this is how it will be achieved" naming options) are not a good fit IMO:

"Relaxing" the CPU is one specific possibility for what the JVM might want to do to improve the performance and responsiveness of a spin wait loop. E.g. The JVM might achieve the desired improvement by doing other things in conjunction with, or in place of relaxing the CPU. Such as affecting scheduling priority or affinity, or doing some other thing that might reduce the likelihood of yielding the CPU. In addition , depending on platform, relaxing the CPU may be the wing thing to do: i.e. Some of the CPU-relaxing options on some platforms dramatically reduce the performance of a spin wait loops and increase their reaction time (rather than improve and reduce).

I wanted the name to suggest intent without dictating implementation, and for the spec to make it clear that improving the performance of a spin wait loop construct is the intended (or hoped for) result without committing to actually achieving that. The runtime may choose to ignore the indication, but it would be surprising for it to make things "worse" for the calling spin wait loop compared to code that doesn't make the same call.


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.

System.gc() can be thought of as "I'm suggesting to the JVM that now is a good time to perform GC", so it's as much about the state of things (known to caller, unknown to JVM or else this wouldn't be needed).  We can agree to disagree here, but I don't see "good time to run GC" vs "good time to relax the CPU" as having any strong semantic differences.

System.gc() says "Runs the garbage collector". A name like System.onGC() would mean "I'm running the garbage collector, and you may want to know that (and do something about it)...". 

Runtime.onSpinWait() means "I'm doing a spin wait, and you might want to know about that (and do something about it)"


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.
 
I should've been clearer, but I meant spinLoopHint on Thread was a better proposal.  I agree that Runtime isn't the right place for something of that name.

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.

Agreed.  Ultimately someone will be unhappy with the name and/or placement, but while these options are being discussed I think it'd be good to hear multiple viewpoints.

On Tue, Dec 1, 2015 at 9:13 AM, Martin Thompson <[hidden email]> wrote:

On 1 December 2015 at 13:46, Vitaly Davidovich <[hidden email]> wrote:
Relax was a suggested name that fits with the current Linux kernel convention. However it was felt this suggested implementation rather than notifying state.

Yes, 'relax' is a well known term for this, and sticking to known conventions/terms is desirable.  I don't see how it suggests implementation though, nor even if it did suggest anything, why that's a bad thing.  If we want to avoid any suggestions, let's call it "foobar" :).

Thread.relax() was my initial suggestion. I'll leave it to the others for why they did not think this was suitable.
 
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.

Martin...


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest