Spin Loop Hint support: Draft JEP proposal (original) (raw)

Rezaei, Mohammad A. Mohammad.Rezaei at gs.com
Tue Oct 6 14:54:57 UTC 2015

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-bounces at openjdk.java.net] On Behalf Of Gil Tene Sent: Tuesday, October 06, 2015 10:05 AM To: Andrew Haley Cc: hotspot-dev at openjdk.java.net; core-libs-dev at 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 <aph at 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.

More information about the hotspot-dev mailing list