> On Oct 6, 2015, at 7:54 AM, Rezaei, Mohammad A. <mohammad.rez...@gs.com> > wrote: > > Thread.yield(), Thread.sleep(), Thread.spinLoopHint()?
That's probably a good place, especially since it doesn't add a new class. Will need feedback about the concerns of adding methods to existing commonly used classes though. E.g. with non-static methods (which this isn't) there is often the "what if someone already has a xyz() method in a subclass" concern. Less of an issue with static methods. > Somehow, it feels right (as in consistent), but also off at the same time (as > in, why are these on Thread). > > I'd take consistent over bespoke-one-static-method-class, unless there was a > concerted effort to consolidate other related api/concerns. > > Thanks > Moh > >> -----Original Message----- >> From: core-libs-dev [mailto: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 >> >> >> >> Sent from Gil's iPhone >> >>> On Oct 6, 2015, at 1:16 AM, Andrew Haley <a...@redhat.com> 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 it's not really about >>>> concurrency). I'm looking for a proper Java SE spec'ed way to do >>>> this. So sun.misc.* won't work. I'm sure we don't want another >>>> Unsafe for people to abuse... >>>> >>>> But naming the class and method is the smaller, easier detail. Right? ;-) >>> >>> 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? >> >> The same can be asked about Thread.notify(). >> >> To me, spinKoopHint() fits in (as in "probably a method in the same class") >> with other performance-oriented hints. Like prefetch variants (which we don't >> have but also probably need. E.g. prefetchWithIntentToWrite()). And placing >> prefetch hints in j.u.c would not make much sense.
