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

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 1 10:32:52 EST 2015


>
> 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 <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/3dffd6e6/attachment.html>


More information about the Concurrency-interest mailing list