Spin Loop Hint support: Draft JEP proposal

[Vitaly Davidovich]

Ok, so the suggestion is to place this into some exported jdk.X package,
where X isn't "internal"? What are the practical implications for a non-JDK
user of this, beyond those APIs subject to (more aggressive) change? If
this path is taken, I'm still unclear on what needs to happen to have it
promoted to SE.

sent from my phone
On Oct 7, 2015 6:57 PM, "joe darcy" <joe.darcy at oracle.com> wrote:

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