Spin Loop Hint support: Draft JEP proposal

[joe darcy]

On 10/7/2015 3:38 PM, Vitaly Davidovich wrote:
>
> A key motivator behind this JEP is to allow non-JDK users to get 
> access to this instruction in a cheap manner - how is making it 
> jdk-internal addressing that? How long would it be in jdk internal 
> before being blessed for SE? What would need to happen for that 
> blessing to take place?
>

The JDK has a public API that is a proper superset of the Java SE API.

The Java SE API historically includes the java.* and javax.* packages. 
(In Java SE 9, this API will be redefined in terms of modules.) The JDK 
API in addition includes the exported portions of com.sun.* and more 
recently the exported portions of jdk.*. (Note that sun.* and 
jdk.internal.* and not part of the exported API even if people have 
treated them as such ;-)

We have more flexibility and options for changing the exported JDK API 
that is not part of Java SE.

-Joe

> I understand that removing APIs in SE is challenging, but 
> implementations are allowed to be nops so maintenance burden should be 
> minimal, if any.  If something better comes along, then I don't see 
> why this method couldn't be deprecated and then removed in a 
> subsequent major release.  Right now, it doesn't look like anyone is 
> proposing any better solution to the problem this JEP addresses.  
> Otherwise, this is just staying with status quo instead of at least 
> moving in the right direction, even if not the final destination in X 
> years.
>
> sent from my phone
>
> On Oct 7, 2015 5:23 PM, "joe darcy" <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     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
>