Spin Loop Hint support: Draft JEP proposal

[Rezaei, Mohammad A.]

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.