Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? 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.
