Spin Loop Hint support: Draft JEP proposal

[Joseph D. Darcy]

On 10/6/2015 6:28 PM, Gil Tene wrote:
>> On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>
>> On 10/04/2015 12:22 PM, Gil Tene wrote:
>>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes.
>>>
>> Some background: about two years ago, Dave Dice and I put together
>> a pre-jep proposal for JVM support for recent CPU features covering:
>>
>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted);
>> (2) Core topology/neighborhood information and;
>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient
>> on non-transactional processors.
>>
>> My understanding of the result of this effort was that Oracle JVM engineers
>> didn't think they had resources to do this for jdk9. It didn't occur to
>> me that non-Oracle contributors might want to cherry-pick one (some
>> of (1) above). It seems plausible to do this, but only if designed
>> as the first of some possible enhanced support along these lines.
> Good point. But that's what an actual community is about. Isn't it?
>
> We (Azul) are volunteering the resources for spinloopHint(). Including
> experimentation, implementation, testing, and even a TCK (which in this case
> will be trivial). So the vast majority of resources needed will not be coming
> other budgeted jdk9 resources.
>
> I certainly recognize that there will still be work involved that others will
> end up having to do: reviewing, arguing, contributing opinions, etc., as well
> as integrating the work into the whole. But this specific proposed JEP is about
> as narrow and low risk as you can get. especially from a specification point of
> view (e.g. intrinsic implementation can be left under a flag if deemed risky to
> stability or schedule).
>
> As for fitting in with larger-picture or theme things (listed above). I think that
> agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint()
> idea, or a create new class that other hints will go into in the future, and where?).
> But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM,
> and affinity. Work. While we can think of them all as "support for recent CPU features",
> they are very different (and probably have multiple other unrelated groupings).
>
> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion
> on the thread). So does a discussion about a capturing abstraction like synchronic
> (raised in concurrency interest), But given the actual common uses already waiting
> for a spinLoopHint(), the very tangible and immediate benefit it shows,  and the fact that
> most of the use cases wouldn't be able to make use of MWAIT (or the like), and some
> won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP
> is not just a good "shortcut", but also an actual stand-alone feature need.
>

Taking a long-term view, it seems to me premature to burn this kind of 
hint into the Java SE API (effectively) forever in the absence of 
experience that the hint in this form is useful and will continue to be 
useful in 5 years, 10 years, etc.

If the hint started out as a JDK-specific API, there would be (some) 
more room to modify or drop the API in the future, leaving open the 
possibility of migrating the functionality to the Java SE API too.

-Joe