Re: Spin Loop Hint support: Draft JEP proposal

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

Re: Spin Loop Hint support: Draft JEP proposal

Doug Lea
On 10/04/2015 12:22 PM, Gil Tene wrote:
> I would like to circulate this draft JEP proposal for initial review and consensus building purposes.
>

Some background: about two years ago, Dave Dice and I put together
a pre-jep proposal for JVM support for recent CPU features covering:

(1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted);
(2) Core topology/neighborhood information and;
(3) 2CAS, as a foothold on HTM that could still be reasonably efficient
on non-transactional processors.

My understanding of the result of this effort was that Oracle JVM engineers
didn't think they had resources to do this for jdk9. It didn't occur to
me that non-Oracle contributors might want to cherry-pick one (some
of (1) above). It seems plausible to do this, but only if designed
as the first of some possible enhanced support along these lines.

-Doug



_______________________________________________
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 proposal

Gil Tene

> On Oct 6, 2015, at 1:02 PM, Doug Lea <[hidden email]> wrote:
>
> On 10/04/2015 12:22 PM, Gil Tene wrote:
>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes.
>>
>
> Some background: about two years ago, Dave Dice and I put together
> a pre-jep proposal for JVM support for recent CPU features covering:
>
> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted);
> (2) Core topology/neighborhood information and;
> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient
> on non-transactional processors.
>
> My understanding of the result of this effort was that Oracle JVM engineers
> didn't think they had resources to do this for jdk9. It didn't occur to
> me that non-Oracle contributors might want to cherry-pick one (some
> of (1) above). It seems plausible to do this, but only if designed
> as the first of some possible enhanced support along these lines.
Good point. But that's what an actual community is about. Isn't it?

We (Azul) are volunteering the resources for spinloopHint(). Including
experimentation, implementation, testing, and even a TCK (which in this case
will be trivial). So the vast majority of resources needed will not be coming
other budgeted jdk9 resources.

I certainly recognize that there will still be work involved that others will
end up having to do: reviewing, arguing, contributing opinions, etc., as well
as integrating the work into the whole. But this specific proposed JEP is about
as narrow and low risk as you can get. especially from a specification point of
view (e.g. intrinsic implementation can be left under a flag if deemed risky to
stability or schedule).

As for fitting in with larger-picture or theme things (listed above). I think that
agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint()
idea, or a create new class that other hints will go into in the future, and where?).
But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM,
and affinity. Work. While we can think of them all as "support for recent CPU features",
they are very different (and probably have multiple other unrelated groupings).

MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion
on the thread). So does a discussion about a capturing abstraction like synchronic
(raised in concurrency interest), But given the actual common uses already waiting
for a spinLoopHint(), the very tangible and immediate benefit it shows,  and the fact that
most of the use cases wouldn't be able to make use of MWAIT (or the like), and some
won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP
is not just a good "shortcut", but also an actual stand-alone feature need.

> -Doug
>
>
>


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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP proposal

Gil Tene

> On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy <[hidden email]> wrote:
>
>
> On 10/6/2015 6:28 PM, Gil Tene wrote:
>>> On Oct 6, 2015, at 1:02 PM, Doug Lea <[hidden email]> wrote:
>>>
>>> On 10/04/2015 12:22 PM, Gil Tene wrote:
>>>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes.
>>>>
>>> Some background: about two years ago, Dave Dice and I put together
>>> a pre-jep proposal for JVM support for recent CPU features covering:
>>>
>>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted);
>>> (2) Core topology/neighborhood information and;
>>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient
>>> on non-transactional processors.
>>>
>>> My understanding of the result of this effort was that Oracle JVM engineers
>>> didn't think they had resources to do this for jdk9. It didn't occur to
>>> me that non-Oracle contributors might want to cherry-pick one (some
>>> of (1) above). It seems plausible to do this, but only if designed
>>> as the first of some possible enhanced support along these lines.
>> Good point. But that's what an actual community is about. Isn't it?
>>
>> We (Azul) are volunteering the resources for spinloopHint(). Including
>> experimentation, implementation, testing, and even a TCK (which in this case
>> will be trivial). So the vast majority of resources needed will not be coming
>> other budgeted jdk9 resources.
>>
>> I certainly recognize that there will still be work involved that others will
>> end up having to do: reviewing, arguing, contributing opinions, etc., as well
>> as integrating the work into the whole. But this specific proposed JEP is about
>> as narrow and low risk as you can get. especially from a specification point of
>> view (e.g. intrinsic implementation can be left under a flag if deemed risky to
>> stability or schedule).
>>
>> As for fitting in with larger-picture or theme things (listed above). I think that
>> agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint()
>> idea, or a create new class that other hints will go into in the future, and where?).
>> But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM,
>> and affinity. Work. While we can think of them all as "support for recent CPU features",
>> they are very different (and probably have multiple other unrelated groupings).
>>
>> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion
>> on the thread). So does a discussion about a capturing abstraction like synchronic
>> (raised in concurrency interest), But given the actual common uses already waiting
>> for a spinLoopHint(), the very tangible and immediate benefit it shows,  and the fact that
>> most of the use cases wouldn't be able to make use of MWAIT (or the like), and some
>> won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP
>> is not just a good "shortcut", but also an actual stand-alone feature need.
>>
>
> Taking a long-term view, it seems to me premature to burn this kind of hint into the Java SE API (effectively) forever in the absence of experience that the hint in this form is useful and will continue to be useful in 5 years, 10 years, etc.
>
> If the hint started out as a JDK-specific API, there would be (some) more room to modify or drop the API in the future, leaving open the possibility of migrating the functionality to the Java SE API too.
>
> -Joe
While I don't disagree with the need for long term thinking, I think this JEP represents exactly that. It is hardly "premature". "Very late" is probably a much better description.

There is overwhelming evidence and experience showing that this exact form of hint is useful, and will likely continue to be useful for a decade or more. Spin hinting isn't something new. This hint technique (include an explicit instruction or function call hinting that you are in a spin loop) has been dominantly and beneficially used for over a decade in virtually all spinning code *other* than Java. E.g. Linux (and probably all other OSs) uses this for virtually all kernel spinning situations on x86 and PowerPC. POSIX libraries do so too in mutexes and semaphores in user mode. Even the JVM's own custom C++ spinning code has been doing it for many years. It is only pure Java code that has been deprived this ability for the past decade. And in the many-core world we've been living in for at least 5 years, even on commodity hardware, the lack really hurts.

This JEP is a fairly late reaction to the very patient requests of a substantial set of Java developers. The community of people doing performant messaging and latency sensitive stuff with Java has been asking for this for a long time as well. Usually with variants of sentences like "Our C and C++ versions of these things use a PAUSE instruction, but in Java we have no way to make that happen. As a result, the reaction time of our Java spin loops is unnecessarily slower than non-Java setups, and our metrics suffer". People often phrase their request as "I'd like PAUSE instruction API in Java". The JEP is aiming for a platform-independent way to express that.

—Gil.





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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP proposal

Doug Lea
In reply to this post by Gil Tene
On 10/06/2015 09:28 PM, Gil Tene wrote:
>
> As for fitting in with larger-picture or theme things (listed above). I think that
> agonizing over the choice of where to put this is important

To avoid the kinds of problems we later saw when basic JVM methods were
placed in odd places just for the sake of appearances (e.g., park/unpark),
the best choice seems to be class Thread, as in:

class Thread { //
   /**
    * A hint to the platform that the current thread is momentarily
    * unable to progress. ... add more guidance ...
    */
   void spinYield();
}

In principle, this would also allow the implementation to do an actual
yield on uniprocessors or when the load average is high. Probably not
in initial implementation though.

Adding a method to class Thread risks name clashes with existing
methods introduced in subclasses. So this might need a clunkier name
to effectively eliminate the possibility.

An analogous method could also be added (now or later)
for MWAIT-based support for waits on the thread's park semaphore
(which is more tractable than doing so for an arbitrary variable).

An alternative to either is to add optional arguments to
yield and park providing a hint about whether to context-switch.

Joe Darcy: Thread.yield does set a precedent here:

* A hint to the scheduler that the current thread is willing to yield
* its current use of a processor. The scheduler is free to ignore this
* hint.


-Doug

_______________________________________________
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 proposal

David M. Lloyd-3
On 10/08/2015 05:58 AM, Doug Lea wrote:

> On 10/06/2015 09:28 PM, Gil Tene wrote:
>>
>> As for fitting in with larger-picture or theme things (listed above).
>> I think that
>> agonizing over the choice of where to put this is important
>
> To avoid the kinds of problems we later saw when basic JVM methods were
> placed in odd places just for the sake of appearances (e.g., park/unpark),
> the best choice seems to be class Thread, as in:
>
> class Thread { //
>    /**
>     * A hint to the platform that the current thread is momentarily
>     * unable to progress. ... add more guidance ...
>     */
>    void spinYield();
> }
>
> In principle, this would also allow the implementation to do an actual
> yield on uniprocessors or when the load average is high. Probably not
> in initial implementation though.
>
> Adding a method to class Thread risks name clashes with existing
> methods introduced in subclasses. So this might need a clunkier name
> to effectively eliminate the possibility.

If the method is static, then the impact of a clashing name should be
fairly minimal.

--
- DML
_______________________________________________
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 proposal

Vitaly Davidovich
In reply to this post by Doug Lea

I agree with David that it should be static though; it doesn't really make sense to be instance.

sent from my phone

On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" <[hidden email]> wrote:
Hi Doug,

Brilliant thought, absolutely…. so obvious that it is completely hidden in plain sight. In the past dumping these things into unsafe was a huge mistake. It’s like a back alley for homeless behavior. If you think about it, it’s the thread that would be spinning so it’s obviously the thread that needs the hint. It should own the behavior… Very clear thinking.

Regards,
Kirk

> On Oct 8, 2015, at 12:58 PM, Doug Lea <[hidden email]> wrote:
>
> On 10/06/2015 09:28 PM, Gil Tene wrote:
>>
>> As for fitting in with larger-picture or theme things (listed above). I think that
>> agonizing over the choice of where to put this is important
>
> To avoid the kinds of problems we later saw when basic JVM methods were
> placed in odd places just for the sake of appearances (e.g., park/unpark),
> the best choice seems to be class Thread, as in:
>
> class Thread { //
>  /**
>   * A hint to the platform that the current thread is momentarily
>   * unable to progress. ... add more guidance ...
>   */
>  void spinYield();
> }
>
> In principle, this would also allow the implementation to do an actual
> yield on uniprocessors or when the load average is high. Probably not
> in initial implementation though.
>
> Adding a method to class Thread risks name clashes with existing
> methods introduced in subclasses. So this might need a clunkier name
> to effectively eliminate the possibility.
>
> An analogous method could also be added (now or later)
> for MWAIT-based support for waits on the thread's park semaphore
> (which is more tractable than doing so for an arbitrary variable).
>
> An alternative to either is to add optional arguments to
> yield and park providing a hint about whether to context-switch.
>
> Joe Darcy: Thread.yield does set a precedent here:
>
> * A hint to the scheduler that the current thread is willing to yield
> * its current use of a processor. The scheduler is free to ignore this
> * hint.
>
>
> -Doug
>


_______________________________________________
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 proposal

Doug Lea
In reply to this post by David M. Lloyd-3
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 momentarily
>>     * unable to progress. ... add more guidance ...
>>     */
>>    void spinYield();

should be:
       public static void spinYield();

>> }
>>
>> In principle, this would also allow the implementation to do an actual
>> yield on uniprocessors or when the load average is high. Probably not
>> in initial implementation though.
>>
>> Adding a method to class Thread risks name clashes with existing
>> methods introduced in subclasses. So this might need a clunkier name
>> to effectively eliminate the possibility.
>
> If the method is static, then the impact of a clashing name should be fairly
> minimal.
>

Right. For statics, pretty much the only concern is whether
reflective mechanics (Class.getMethod etc) return unexpected
entries that would break existing code. The name "spinYield"
seems unlikely enough to be a problem though.

-Doug


_______________________________________________
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 proposal

Paul Sandoz

> On 8 Oct 2015, at 18:33, [hidden email] wrote:
>
> 2015/10/8 7:56 -0700, [hidden email]:
>>>> ...
>>>>
>>>> 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 void spinYield();
>
> Yes -- let's keep this simple.  It's just one method, another hint
> in j.l.Thread which can be ignored (or not) by the VM.
>
> This concept seems sufficiently well understood, based on its use
> in other platforms, that putting it directly into j.l.Thread is not
> a huge risk.  I don't see a strong need for this to start out as a
> JDK-specific API.
>
+1

Paul.

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

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP proposal

Viktor Klang
+1

On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz <[hidden email]> wrote:

> On 8 Oct 2015, at 18:33, [hidden email] wrote:
>
> 2015/10/8 7:56 -0700, [hidden email]:
>>>> ...
>>>>
>>>> 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 void spinYield();
>
> Yes -- let's keep this simple.  It's just one method, another hint
> in j.l.Thread which can be ignored (or not) by the VM.
>
> This concept seems sufficiently well understood, based on its use
> in other platforms, that putting it directly into j.l.Thread is not
> a huge risk.  I don't see a strong need for this to start out as a
> JDK-specific API.
>

+1

Paul.

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




--
Cheers,

_______________________________________________
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 proposal

Haim Yadid
In reply to this post by Doug Lea
+1 as well :)

BR,
    Haim Yadid


> On 8 באוק׳ 2015, at 17:56, Doug Lea <[hidden email]> 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 momentarily
>>>    * unable to progress. ... add more guidance ...
>>>    */
>>>   void spinYield();
>
> should be:
>      public static void spinYield();
>
>>> }
>>>
>>> In principle, this would also allow the implementation to do an actual
>>> yield on uniprocessors or when the load average is high. Probably not
>>> in initial implementation though.
>>>
>>> Adding a method to class Thread risks name clashes with existing
>>> methods introduced in subclasses. So this might need a clunkier name
>>> to effectively eliminate the possibility.
>>
>> If the method is static, then the impact of a clashing name should be fairly
>> minimal.
>
> Right. For statics, pretty much the only concern is whether
> reflective mechanics (Class.getMethod etc) return unexpected
> entries that would break existing code. The name "spinYield"
> seems unlikely enough to be a problem though.
>
> -Doug
>
>
> _______________________________________________
> 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 proposal

Doug Lea
In reply to this post by Doug Lea
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.

For these, the next question is whether this should be more
like Thread.yield() vs Thread.sleep(). If it could be like
sleep, then new a API might not be needed: JVMs could
implement sleep(0, 1) (or any small value of nanosec arg)
using a PAUSE instruction on platforms supporting them.
But sleep is also required to check interrupt status,
which means that at least one extra load would be needed
in addition to PAUSE. So it seems that something yield-like
(with no obligation to check interrupt) is still desirable,
leading either to my original suggestion:

   /**
    * A hint to the platform that the current thread is momentarily
    * unable to progress...
    */
   public static void spinYield();

OR something more analogous to sleep, but without interrupt check:

  /**
   * A hint to the platform that the current thread is unlikely
   * to progress for the indicated duration in nanoseconds...
   */
   public static void yield(long nanoSeconds);

When available, JVMs would implement small values via PAUSE,
larger by calling plain yield(), but in no case promising to
return in either at least or at most the given duration.
While it is a little odd, it seems to cover John Rose's desire
to force an argument dependency.

I think either of these would be OK.

We'd use this functionality in a few places inside java.util.concurrent.
We can't do so as aggressively as some users might like: we
generally bound spin-then-block constructions to an approximation
of best-case unavailability (lock-hold etc) times, so as to
work OK when systems are heavily loaded. When we have done more
than this, we have gotten justifiable complaints. But we also
have "try" and "poll" forms of almost everything so users can
add additional spins themselves. Or create custom sync using
base capabilities.

Back to the question of monitor-like constructions:

Low-level memory-wait instructions are limited in what they
can wait for -- basically only changes at fixed addresses.
This is not an easy fit for GCed languages where the address
of a variable might change. However, there is at least one
case where this can work: park/unpark are (and are nearly forced
to be) implemented using an underlying native-level semaphore.
So it should be possible to at least sometimes use MWAIT
inside park to reduce unproductive context switches.
The "sometimes" part might vary across platforms.
In particular, the implementation of LockSupport.parkNanos
could always just invoke an MWAIT-based intrinsic for small
arguments. It would be great if people working on hotspot
explored such options.

So for this particular application of MWAIT-like support
(which should be vastly more common than other uses anyway),
we could side-step for now analogs of proposed C++ "synchronics"
and the like that would require unknown mechanics on
still-unreleased VarHandles.

-Doug

_______________________________________________
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 proposal

Doug Lea
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 hints.
>

I've been focussing on the spec, which still seems to best support
this naming. Let's try fleshing out some more (for no-arg version).

   /**
    * A hint to the platform that the current thread is momentarily
    * unable to progress until the occurrence of one or more actions
    * of one or more other threads. The method is mainly applicable
    * in spin-then-block constructions entailing a bounded number
    * of re-checks of a condition, separated by spinYield(), followed
    * if necessary with use of a blocking synchronization mechanism.
    */
   public static void spinYield();

What should be the response to this hint? When applicable
and available, the JVM should just issue PAUSE. But on a uniprocessor,
or when load average is easily detected to be high, or
on a tightly packed cloud node, a plain yield or something
along those lines might be a better use of this hint, that
the spec should not rule out. Also, I believe that some x86
hypervisors intercept PAUSE and do something roughly similar
after repeated invocations.

> While the spinYield() example in your e-mail below can work from a semantic
> point of view in the same code, IMO the word "yield" suggests the exact
> opposite of what spnLoopHint() is intending to do or hint at

Maybe. If you are on a system with load > #cpus, or with
certain forms of hypervisor,  or without a PAUSE instruction,
spinYield might not improve responsiveness but might still
improve system throughput.

-Doug

_______________________________________________
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 proposal

Doug Lea

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 "…momentarily unable to progress until the
> occurrence of one or more actions of one or more other threads. " is true:
> while (!(done || (count++ > threshold))) { spinLoopHint(); } can progress
> without any action by any other thread.

OK, this needs better wording to rule out silly interpretations
about loop bounds. See below.

>
> As noted in my proposed JavaDoc, I see the primary indication of the hint to
> be that the reaction time to events that would cause the loop to exit (e.g.
> in nanosecond units) is more important to the caller than the speed at which
> the loop is executing (e.g. in "number of loop iterations per second" units).

Sure. This can also be stated:

class Thread { ...
  /**
   * A hint to the platform that the current thread is momentarily
   * unable to progress until the occurrence of one or more actions of
   * one or more other threads (or that its containing loop is
   * otherwise terminated).  The method is mainly applicable in
   * spin-then-block constructions entailing a bounded number of
   * re-checks of a condition, separated by spinYield(), followed if
   * necessary with use of a blocking synchronization mechanism.  A
   * spin-loop that invokes this method on each iteration is likely to
   * be more responsive than it would otherwise be.
   */
   public static void spinYield();
}

> Anyone running indefinite spin loops on a uniprocessor deserves whatever they
> get. Yielding in order to help them out is not mercy. Let Darwin take care of
> them instead.
>
> But indefinite user-mode spinning on many-core systems is a valid and common
> use case (see the disruptor link in my previous e-mail).

> In such situations the spinning loop should just be calling yield(), or
> looping for a very short count (like your magic 64) and then yielding. A
> "magically choose for me whether reaction time or throughput or being nice to
> others is more important" call is not a useful hint IMO.
>
> Like in my uniprocessor comment above, any program spinning indefinitely (or
> for a non-trivial amount of time) with load > # cpus deserves what it gets.

The main problem here is that there are no APIs reporting whether
load > # cpus, and no good prospects for them either, especially
considering the use of hypervisors (that may intentionally mis-report)
and tightly packed cloud nodes where the number of cpus currently
available to a program may depend on random transient effects of
co-placement with other services running on that node.

And given that programmers cannot portably comply, the method must
allow implementations that take the best course of action known to the JVM.

Despite all of the above, I agree that an OK initial hotspot implementation
is just to emit PAUSE if on x86 else no-op. It might be worth then
experimenting with randomized branching etc on other platforms, and
someday further exploring some cheap form of load detection, perhaps
kicking in only upon repeated invocation.

-Doug


_______________________________________________
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 proposal

Paul Sandoz

> On 1 Dec 2015, at 03:58, Gil Tene <[hidden email]> 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 to add a new static method to the Runtime class:
>
> 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 activities.  When invoked within each iteration, this
>      * method typically improves performance of spin wait loop
>      * constructions.
>      */
>     public static void onSpinWait() {};
> }
>
Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP.

If you like I can help guide this through the JEP process.


> See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
>
> As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk.
>

I agree, the JDK and hotspot patches (for x86 support) are quite small.

Paul.

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

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin Loop Hint support: Draft JEP proposal

Vitaly Davidovich
In reply to this post by Doug Lea

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 my phone

On Nov 30, 2015 9:59 PM, "Gil Tene" <[hidden email]> 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 to add a new static method to the Runtime class:

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 activities.  When invoked within each iteration, this
      * method typically improves performance of spin wait loop
      * constructions.
      */
     public static void onSpinWait() {};
}

See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).

As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk.

— Gil.






_______________________________________________
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 proposal

Doug Lea
In reply to this post by Paul Sandoz
On 12/01/2015 05:36 AM, Paul Sandoz wrote:

>
>> On 1 Dec 2015, at 03:58, Gil Tene <[hidden email]> 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 activities.  When invoked within each iteration, this
>>       * method typically improves performance of spin wait loop
>>       * constructions.
>>       */
>>      public static void onSpinWait() {};
>> }
>>
>
> Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP.
>


Or maybe not. Recent experience suggests that it is hard to add a brief
explanatory note or usage guidance without saying something
confusing or wrong wrt usages focussing on latency, throughput,
or power -- these effects may vary across processors with
different instructions (possibly just no-op) used to implement it.
Not a lot, but this accounts for the bland wording of
"typically improves performance".

-Doug

_______________________________________________
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 proposal

Viktor Klang
In reply to this post by Vitaly Davidovich
While we are painting the bikeshed, what about `powerNap()`

On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich <[hidden email]> 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 seems inappropriate as the method itself isn't doing any waiting.  What was wrong with the original spinLoopHint name? Or cpuRelax()?

sent from my phone

On Nov 30, 2015 9:59 PM, "Gil Tene" <[hidden email]> 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 to add a new static method to the Runtime class:

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 activities.  When invoked within each iteration, this
      * method typically improves performance of spin wait loop
      * constructions.
      */
     public static void onSpinWait() {};
}

See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).

As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk.

— Gil.






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




--
Cheers,

_______________________________________________
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 proposal

thurstonn
In reply to this post by Paul Sandoz
+1 for the API note

OK, I guess it is inherently fraught, but I still think it would be useful,
e.g. when clarifying when  (how often) to invoke it. i.e. someone might (reasonably?) conclude that you should do:


Runtime.onSpinLoop()
while (spin-until-condition) {}


instead of:

while (spin-until-condition)
{
    Runtime.onSpinLoop()
}