Spin Loop Hint support: Draft JEP proposal
Gil Tene
gil at azulsystems.com
Mon Oct 5 21:01:47 UTC 2015
> On Oct 5, 2015, at 2:04 AM, Alan Bateman <Alan.Bateman at 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.
More information about the core-libs-dev
mailing list