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

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 1 17:09:38 EST 2015


>
> 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 <gil at azul.com> wrote:

>
>
> Sent from Gil's iPhone
>
> On Dec 1, 2015, at 8:29 AM, Vitaly Davidovich <vitalyd at gmail.com> 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 <gil at azul.com> wrote:
>
>>
>>
>> Sent from Gil's iPhone
>>
>> On Dec 1, 2015, at 7:32 AM, Vitaly Davidovich <vitalyd at gmail.com> 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 <gil at azul.com> wrote:
>>
>>>
>>>
>>> Sent from Gil's iPhone
>>>
>>> On Dec 1, 2015, at 6:45 AM, Vitaly Davidovich <vitalyd at gmail.com> 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 <mjpt777 at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On 1 December 2015 at 13:46, Vitaly Davidovich <vitalyd at gmail.com>
>>>> 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
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151201/8faff789/attachment-0001.html>


More information about the Concurrency-interest mailing list