Spin Loop Hint support: Draft JEP proposal

[Gil Tene]

> 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.

> -Doug
> 
> 
>