> On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy <joe.da...@oracle.com> wrote: > > > On 10/6/2015 6:28 PM, Gil Tene wrote: >>> On Oct 6, 2015, at 1:02 PM, Doug Lea <d...@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
While I don't disagree with the need for long term thinking, I think this JEP represents exactly that. It is hardly "premature". "Very late" is probably a much better description. There is overwhelming evidence and experience showing that this exact form of hint is useful, and will likely continue to be useful for a decade or more. Spin hinting isn't something new. This hint technique (include an explicit instruction or function call hinting that you are in a spin loop) has been dominantly and beneficially used for over a decade in virtually all spinning code *other* than Java. E.g. Linux (and probably all other OSs) uses this for virtually all kernel spinning situations on x86 and PowerPC. POSIX libraries do so too in mutexes and semaphores in user mode. Even the JVM's own custom C++ spinning code has been doing it for many years. It is only pure Java code that has been deprived this ability for the past decade. And in the many-core world we've been living in for at least 5 years, even on commodity hardware, the lack really hurts. This JEP is a fairly late reaction to the very patient requests of a substantial set of Java developers. The community of people doing performant messaging and latency sensitive stuff with Java has been asking for this for a long time as well. Usually with variants of sentences like "Our C and C++ versions of these things use a PAUSE instruction, but in Java we have no way to make that happen. As a result, the reaction time of our Java spin loops is unnecessarily slower than non-Java setups, and our metrics suffer". People often phrase their request as "I'd like PAUSE instruction API in Java". The JEP is aiming for a platform-independent way to express that. —Gil.
