Spin Loop Hint support: Draft JEP proposal

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.


>-----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 core-libs-dev mailing list