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

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


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

>
>
> Sent from Gil's iPhone
>
> On Dec 1, 2015, at 8:02 AM, Vitaly Davidovich <vitalyd at gmail.com> 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 <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.
>>
>> 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 <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/238d1a5f/attachment-0001.html>


More information about the Concurrency-interest mailing list