Spin Loop Hint support: Draft JEP proposal

[Gil Tene]

> On Oct 6, 2015, at 7:54 AM, Rezaei, Mohammad A. <Mohammad.Rezaei at 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-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.