> On Oct 5, 2015, at 2:04 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 04/10/2015 17:22, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and >> consensus building purposes. >> >> I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec >> perspective, the main change it suggests is the addition of a method (and >> probably a class to hold it) to the core libraries. And intrinsifying >> implementations would involve changes in HotSpot (see prototype WebRev links >> included below). >> >> Draft JEP follows inline... >> >> — Gil. >> > I don't see any mention in the JEP about existing mechanisms to give hints to > the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate > (JDK-8076112). Just wondering if there is an alternative to explore where > something like @Spinloop int ignore; would emit the PAUSE. This would at > least give a starting point for usages in the JDK. The bigger question is > whether to expose such runtime hints in an API. It's very much for the > advanced developer and if an API is really needed then it might be something > for a JDK-specific API.
Alan, The JEP is not about performance hints in general, it's about (and only about) spin loop hints. While there are many "spelling" options possible, I don't think annotations will fit well. The needs of a spinLoopHint seem to be very different from those of the @Contended and @HotSpotIntrinsicCandidate in several way. Annotations have limited places in code where they can be applied. Specifically, they apply to declarations but not to execution. E.g. "@SpinLoop int ignore;" is a declaration: it does not emit any bytecodes. Without actually using the variable "ignore" later in the code, there would be no way to link it to code. The place where actual byte-codes are emitted would need to tie in to the declared variable, which would probably make the "spelling" more cumbersome than a trivial method call (with a hopefully self-explanatory name). — Gil.
