Spin Loop Hint support: Draft JEP proposal (original) (raw)

Joseph D. Darcy joe.darcy at oracle.com
Wed Oct 7 01:50:18 UTC 2015

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

More information about the core-libs-dev mailing list