Spin Loop Hint support: Draft JEP proposal

joe darcy joe.darcy at oracle.com
Wed Oct 7 21:23:07 UTC 2015


On 10/7/2015 1:24 AM, Andrew Haley wrote:
> On 07/10/15 02:50, Joseph D. Darcy wrote:
>> 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.
> This seems to me to be a very odd thing to say.  Of course there is no
> experience with this in Java because it's not been available, but
> there is plenty of experience outside Java.  If this goes into a JDK-
> specific API we'll also have to support it for a long while or we'll
> break programs.  It's not obvious how pushing this outside Java SE
> will aid practical portability.
>
> Also, this hint is very much in tune with the trend to do more in Java
> and less in native code: it moves the barrier between code that must
> be native and can be Java.  That's a good thing.

The most operative phrasing is "a hint *in this form*".

To my knowledge, we don't have an existing hint in the Java SE API which 
uses this proposed mechanism of a possibly no-op API call. Further, the 
proposed hint in this JEP is a singleton without any peers, at least not 
initially.

In other contexts, annotations are used to convey this sort of meta-data 
which doesn't affect the semantics of the code (for some definition of 
semantics) to various tools consuming class files, which can include 
JVMs. Annotations are not an ideal fit here since statements cannot be 
annotated, but one could imagine various workaround with different 
levels of hackery.

I take it that it is difficult / impractical for JVMs to infer which 
loops would benefit from things like pause instructions? Is this an area 
of research?

If something is added to Java SE, it is there practically forever, is 
extremely difficult to jettison, and basically can only be changed in 
platform releases (e.g. can be changed in releases like 8, 9, 10 and not 
changed in 8u60, 9.1, etc.). If something is a JDK API, if there is a 
problem or should be removed, that only take "a long term" (vs forever) 
and it is easier to make changes / additions in minor releases like 9.1.

-Joe



More information about the hotspot-dev mailing list