On 24/02/16 15:56, mark.reinh...@oracle.com wrote:
> 2016/2/23 22:22 -0800, Gil Tene :
>> ...
>>
>> Let's just go with it.
>>
>> Thread.onSpinWait() FTW!
>
> I agree. The "on" prefix is not exclusively reserved for APIs that
> deliver event objects, and in this context it clarifies the meaning
>
On 24/02/2016 18:56, mark.reinh...@oracle.com wrote:
2016/2/23 22:22 -0800, Gil Tene :
...
Let's just go with it.
Thread.onSpinWait() FTW!
I agree. The "on" prefix is not exclusively reserved for APIs that
deliver event objects, and in this context it clarifies the meaning
of the method.
-
Looks like you have Mark's approval, so we're done :).
On Wed, Feb 24, 2016 at 11:06 AM, Ivan Krylov wrote:
> On 24/02/2016 18:20, Vitaly Davidovich wrote:
>
>> If you want, run a poll to get a better feel for what others may think.
>> Doug did that recently for some CompletableFuture behavior c
On 24/02/2016 18:20, Vitaly Davidovich wrote:
If you want, run a poll to get a better feel for what others may
think. Doug did that recently for some CompletableFuture behavior
change proposals. Ultimately, I don't make the call on this anyway so
I'm just giving you my opinion as a would-be use
2016/2/23 22:22 -0800, Gil Tene :
> ...
>
> Let's just go with it.
>
> Thread.onSpinWait() FTW!
I agree. The "on" prefix is not exclusively reserved for APIs that
deliver event objects, and in this context it clarifies the meaning
of the method.
- Mark
On Wednesday, February 24, 2016, Gil Tene wrote:
> onXXX is VERY relevant to this situation. And it's exactly that precedent
> and common convention for event notification calls that drove the choice of
> onSpinWait as a method name. onSpinWait() it is delivering a notification
> [from the callin
onXXX is VERY relevant to this situation. And it's exactly that precedent and
common convention for event notification calls that drove the choice of
onSpinWait as a method name. onSpinWait() it is delivering a notification [from
the calling code to the Runtime, or the Thread] about what is goin
Yes, I was going to mention onXXX being common for event handler names (e.g
onMouseClick), but didn't bother for the same reason you mentioned - it's
irrelevant to this situation.
On Tuesday, February 23, 2016, Paul Benedict wrote:
> The onXXX prefix does have precedent as event handler callback
The onXXX prefix does have precedent as event handler callbacks, but this
method does not fit that purpose. Thus, I agree dropping "on" is sensible.
On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" wrote:
> On Tuesday, February 23, 2016, Doug Lea wrote:
>
> > On 02/23/2016 04:30 PM, Vitaly Davidovic
On Tuesday, February 23, 2016, Doug Lea wrote:
> On 02/23/2016 04:30 PM, Vitaly Davidovich wrote:
>
>> Why not drop the (superfluous, IMO) "on" prefix while you're changing the
>> receiver?
>>
>
> Because then it reads as if the method itself is doing a spinWait.
vs who else logically speaking?
On 02/23/2016 04:30 PM, Vitaly Davidovich wrote:
Why not drop the (superfluous, IMO) "on" prefix while you're changing the
receiver?
Because then it reads as if the method itself is doing a spinWait.
"onSpinWait" is the only proposed name that no one has said they cannot
live with. So, live wit
Why not drop the (superfluous, IMO) "on" prefix while you're changing the
receiver? Thread::spinWait would be in the same style/spirit as
Thread::yield, and I don't think there will be much contention.
On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene wrote:
>
> > On Feb 22, 2016, at 10:11 AM, mark.rein
> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote:
>
> 2016/1/28 9:25 -0800, g...@azul.com:
>> This thread seems to have "hopped away" to the concurrency-interest
>> list in mid-Dec-2015. This posting is intended to capture a summary of
>> reasoning and some of the discussion there s
On 02/22/2016 12:11 PM, mark.reinh...@oracle.com wrote:
2016/1/28 9:25 -0800, g...@azul.com:
This thread seems to have "hopped away" to the concurrency-interest
list in mid-Dec-2015. This posting is intended to capture a summary of
reasoning and some of the discussion there so that we have it in
2016/1/28 9:25 -0800, g...@azul.com:
> This thread seems to have "hopped away" to the concurrency-interest
> list in mid-Dec-2015. This posting is intended to capture a summary of
> reasoning and some of the discussion there so that we have it in the
> record in core-libs-dev. Mostly by including t
So it still hasn't grown on me Gil! :) In particular, placing the method on
Runtime just doesn't make sense to me, even with the "we're notifying the
runtime we're spinning" sentiment. If that's the "bar" for putting things
on Runtime, then a lot more things could (would) go in there; Thread.yield
This thread seems to have "hopped away" to the concurrency-interest list in
mid-Dec-2015. This posting is intended to capture a summary of reasoning and
some of the discussion there so that we have it in the record in core-libs-dev.
Mostly by including the contents of several posts in the contin
2015/11/30 6:58 -0800, g...@azul.com:
> 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 metho
While we are painting the bikeshed, what about `powerNap()`
On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich 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
On 12/01/2015 05:36 AM, Paul Sandoz wrote:
On 1 Dec 2015, at 03:58, Gil Tene 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 invok
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 m
> On 1 Dec 2015, at 03:58, Gil Tene 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
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 { /.
[Sorry for the 4 day delay in response. JavaOne sort of got in the way]
I think we are looking at two separate and almost opposite motivations, each of
which is potentially independently valid. Each can be characterized by
answering the question: "How does adding this to an empty while(!ready) {
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 "…
> On Oct 15, 2015, at 11:32 PM, Doug Lea wrote:
>
> 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 b
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 na
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.
On the name choice: things that include the word "yield" vs. spinLoopHint()::
While the spinYield() example in your
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.
F
+1 as well :)
BR,
Haim Yadid
> On 8 באוק׳ 2015, at 17:56, Doug Lea 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
>>>* un
It seems you suggest to hide this feature "à la" Unsafe to avoid exposing a
new Java SE API. But the move is quite the opposite right now where all
Unsafe "features" will find an exit to a public reliable API which is good
and low latency and performance people is waiting for. JVM already uses the
+1
On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz wrote:
>
> > On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote:
> >
> > 2015/10/8 7:56 -0700, d...@cs.oswego.edu:
> ...
>
> class Thread { //
> /**
> * A hint to the platform that the current thread is momentari
>
> Hi Gil,
>
> Glad to see this being addressed!
>
Me too, this would be a useful addition to the Disruptor.
On 10/04/2015 07:22 PM, Gil Tene wrote:
> > We propose to add a method to the JDK which would be hint that a spin
> > loop is being performed. E.g.
> > jdk.util.PerformanceHints.spinLoopH
On Tue, Oct 6, 2015 at 10:16 AM, Andrew Haley wrote:
>
> Sure. I would have thought, though, that java.util.concurrent was a
> natural home for this. Is there any kind of userland spinlock which
> is not about concurrency?
>
> Andrew.
>
Spinning is not always for a spinlock. Most of the time i
On Oct 8, 2015, at 11:56 PM, Gil Tene wrote:
>
>>
>> On Oct 8, 2015, at 6:18 PM, John Rose wrote:
>>
>> On Oct 8, 2015, at 12:39 AM, Gil Tene wrote:
> … If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8
> and SPARC M7 in a common useful paradigm.
>
>> Also, from a cr
> On Oct 8, 2015, at 6:18 PM, John Rose wrote:
>
> On Oct 8, 2015, at 12:39 AM, Gil Tene wrote:
>>
>> On the one hand:
>>
>> I like the idea of (an optional?) boolean parameter as a means of hinting at
>> the thing that may terminate the spin. It's probably much more general than
>> identif
On Oct 8, 2015, at 12:39 AM, Gil Tene wrote:
>
> On the one hand:
>
> I like the idea of (an optional?) boolean parameter as a means of hinting at
> the thing that may terminate the spin. It's probably much more general than
> identifying a specific field or address. And it can be used to cove
> On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote:
>
> 2015/10/8 7:56 -0700, d...@cs.oswego.edu:
...
class Thread { //
/**
* A hint to the platform that the current thread is momentarily
* unable to progress. ... add more guidance ...
*/
2015/10/8 7:56 -0700, d...@cs.oswego.edu:
>>> ...
>>>
>>> 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 vo
On Thu, Oct 8, 2015 at 1:01 PM, David M. Lloyd
wrote:
>
> If the method is static, then the impact of a clashing name should be
> fairly minimal.
>
>
+1 on this, I do not see the benefit of an instance method either here. But
good idea, Doug, for Thread class and the yield hint :)
--
*The infor
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 voi
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"
wrote:
> Hi Doug,
>
> Brilliant thought, absolutely…. so obvious that it is completely hidden in
> plain sight. In the past dumping these
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 wer
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
On 10/07/2015 09:21 PM, Gil Tene wrote:
> Interesting. I was going off of the 32 bit ARM documentation. Looks like
> ARMv8 improved on that, and did it implicitly (without requiring different
> instructions).
>
> You can see the differences on the unlock path between the 32 bit and 64 bit
> imple
On Oct 7, 2015, at 3:01 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
On Oct 5, 2015, at 2:41 AM, Andrew Haley
mailto:a...@redhat.com>> wrote:
Hi Gil,
On 04/10/15 17:22, Gil Tene wrote:
Summary
Add an API that would allow Java code to hint that a spin loop is
being executed.
I don'
On Oct 5, 2015, at 2:41 AM, Andrew Haley wrote:
>
> Hi Gil,
>
> On 04/10/15 17:22, Gil Tene wrote:
>
>> Summary
>>
>> Add an API that would allow Java code to hint that a spin loop is
>> being executed.
>
>
> I don't think this will work for ARM, which has a rather different
> spinlock mecha
On 10/07/2015 04:45 PM, Gil Tene wrote:
> For ARM, I expect WFE/SEV to need to evolve as well, and for other
> reasons, even fit use within OSs. The current WFE/SEV scheme is not
> scalable. While it probably works ok for spinning at the kernel
> level on hardware that only has s handful of cores,
On 10/07/2015 04:45 PM, Gil Tene wrote:
> In any case, even if it were user-mode-accessible, MWAIT may not appropriate
> for latency-sensitive spinning because it can apparently take 1000s of cycles
> to come out of the C-state modes it goes into.
Oh, yuck. OK, forget it.
Thanks,
Andrew.
Sent from Gil's iPhone
> On Oct 7, 2015, at 1:14 AM, Andrew Haley wrote:
>
>> On 05/10/15 21:43, Gil Tene wrote:
>>
>> I see SpinLoopHint as very separate from things like MONITOR/WAIT
>> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice
>> way until this state changes" inst
On 05/10/15 21:43, Gil Tene wrote:
> I see SpinLoopHint as very separate from things like MONITOR/WAIT
> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice
> way until this state changes" instructions that other architectures
> may have or add.
>
> Mechanisms like MONITOR/WAIT and
> On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy wrote:
>
>
> On 10/6/2015 6:28 PM, Gil Tene wrote:
>>> On Oct 6, 2015, at 1:02 PM, Doug Lea 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 buildi
On 10/6/2015 6:28 PM, Gil Tene wrote:
On Oct 6, 2015, at 1:02 PM, Doug Lea 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
> On Oct 6, 2015, at 1:02 PM, Doug Lea 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
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/PAUS
core-libs-dev-boun...@openjdk.java.net] On Behalf
>> Of Gil Tene
>> Sent: Tuesday, October 06, 2015 10:05 AM
>> To: Andrew Haley
>> Cc: hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>> Subject: Re: Spin Loop Hint support: Draft JEP proposal
>>
>&g
ubject: Re: Spin Loop Hint support: Draft JEP proposal
>
>
>
>Sent from Gil's iPhone
>
>> On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote:
>>
>>> On 06/10/15 05:32, Gil Tene wrote:
>>>
>>> I don't think of this as platform specific.
Although spin lock would also benefit from this, the spinning is also done
when doing message hand off between threads. It's common in low latency
space to monopolize the cpu(s) and spin wait for data to arrive; this is to
avoid parking the thread in kernel when you know arrival rate is very high.
Sent from Gil's iPhone
> On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote:
>
>> On 06/10/15 05:32, Gil Tene wrote:
>>
>> I don't think of this as platform specific. And it's not much lower
>> level than e.g. some java.util.concurrent stuff (but probably
>> doesn't belong in that package because
Hi Gil,
Have you investigated the use of this spin loop hint in j.u.concurrent classes
and other potential areas in the JDK?
I think it would be useful to include some investigation to validate it’s use
and then follow up with updates, perhaps separate to this JEP.
> On 6 Oct 2015, at 06:32,
On 06/10/15 05:32, Gil Tene wrote:
> I don't think of this as platform specific. And it's not much lower
> level than e.g. some java.util.concurrent stuff (but probably
> doesn't belong in that package because it's not really about
> concurrency). I'm looking for a proper Java SE spec'ed way to do
> On Oct 5, 2015, at 1:56 AM, Aleksey Shipilev
> wrote:
>
> Hi Gil,
>
> Glad to see this being addressed!
>
> On 10/04/2015 07:22 PM, Gil Tene wrote:
>> We propose to add a method to the JDK which would be hint that a spin
>> loop is being performed. E.g.
>> jdk.util.PerformanceHints.spinLoop
> On Oct 5, 2015, at 2:04 AM, Alan Bateman wrote:
>
> On 04/10/2015 17:22, Gil Tene wrote:
>> I would like to circulate this draft JEP proposal for initial review and
>> consensus building purposes.
>>
>> I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec
>> perspective, the
I see SpinLoopHint as very separate from things like MONITOR/WAIT (on x86) and
WFE/SEV (on ARM), as well as any other "wait in a nice way until this state
changes" instructions that other architectures may have or add.
Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to potentially wait f
Is this some kind of CPU.yield() (by analogy to Thread.yield())?
I was wondering the same, it feels like a more vague (API abstraction-wise at
least) architecture specific Thread.yield().
Paul.
Thread.sleep(0), Thread.yield() and now PerformanceHints.spinLoopHint()
are all implementation
On 05/10/2015 11:56, Aleksey Shipilev wrote:
* I think spinLoopHint() misses a @HotspotIntrinsicCandidate
annotation. Thanks, -Aleksey
Correct. This prototype was build a little while ago and was based on
OpenJDK 9 build 70.
This annotation was added as part of
https://bugs.openjdk.java.net/br
> I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called.
> Just before entering the spin-loop or at each iteration of the loop?
The latter, e.g. see the benchmark code.
> Is this some kind of CPU.yield() (by analogy to Thread.yield())?
>
I was wondering the same, it feel
On 10/05/2015 05:19 PM, Andrew Haley wrote:
On 10/05/2015 03:59 PM, Peter Levart wrote:
On 10/05/2015 11:41 AM, Andrew Haley wrote:
Hi Gil,
On 04/10/15 17:22, Gil Tene wrote:
Summary
Add an API that would allow Java code to hint that a spin loop is
being executed.
I don't think this will
On 10/05/2015 03:59 PM, Peter Levart wrote:
>
> On 10/05/2015 11:41 AM, Andrew Haley wrote:
>> Hi Gil,
>>
>> On 04/10/15 17:22, Gil Tene wrote:
>>
>>> Summary
>>>
>>> Add an API that would allow Java code to hint that a spin loop is
>>> being executed.
>>
>> I don't think this will work for ARM, w
On 10/05/2015 11:41 AM, Andrew Haley wrote:
Hi Gil,
On 04/10/15 17:22, Gil Tene wrote:
Summary
Add an API that would allow Java code to hint that a spin loop is
being executed.
I don't think this will work for ARM, which has a rather different
spinlock mechanism.
Instead of PAUSE, we wai
Hi Gil,
On 04/10/15 17:22, Gil Tene wrote:
> Summary
>
> Add an API that would allow Java code to hint that a spin loop is
> being executed.
I don't think this will work for ARM, which has a rather different
spinlock mechanism.
Instead of PAUSE, we wait on a lock word with WFE. WFE puts a co
On 04/10/2015 17:22, Gil Tene wrote:
I would like to circulate this draft JEP proposal for initial review and
consensus building purposes.
I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec
perspective, the main change it suggests is the addition of a method (and
probably a
Hi Gil,
Glad to see this being addressed!
On 10/04/2015 07:22 PM, Gil Tene wrote:
> We propose to add a method to the JDK which would be hint that a spin
> loop is being performed. E.g.
> jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve
> to a Java SE API, e.g. java.util.Perf
I would like to circulate this draft JEP proposal for initial review and
consensus building purposes.
I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec
perspective, the main change it suggests is the addition of a method (and
probably a class to hold it) to the core libraries
74 matches
Mail list logo
