Spin Loop Hint support: Draft JEP proposal

[Vitaly Davidovich]

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?

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> 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
>
>