Spin Loop Hint support: Draft JEP proposal

[Jean Philippe Bempel]

It seems you suggest to hide this feature "à la" Unsafe to avoid exposing a
new Java SE API. But the move is quite the opposite right now where all
Unsafe "features" will find an exit to a public reliable API which is good
and low latency and performance people is waiting for. JVM already uses the
PAUSE instruction into the synchronized block implementation before
inflating part which is also a sign of a good behavior that Java users
would like to leverage on their code.

Spinning is here since a long time now, and there is no evidence it will
change in the next year. And even if this is changing, roll backing to a
no-op implementation will be safe anyway.

This JEP starts with a baby step, but some other stuffs are in the pipe
(like Doug's list). The most difficult part is to agree on the API for
future improvement in that area.

*Jean-Philippe Bempel* *|* Software Architect* |* *ULLINK |* T: +33 1 49 95
10 29
| 23-25 rue de Provence | 75009 Paris | *jpbempel at ullink.com*
<jpbempel at ullink.com> |

On Wed, Oct 7, 2015 at 3:50 AM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

>
> On 10/6/2015 6:28 PM, Gil Tene wrote:
>
>> On Oct 6, 2015, at 1:02 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>
>>> On 10/04/2015 12:22 PM, Gil Tene wrote:
>>>
>>>> I would like to circulate this draft JEP proposal for initial review
>>>> and consensus building purposes.
>>>>
>>>> Some background: about two years ago, Dave Dice and I put together
>>> a pre-jep proposal for JVM support for recent CPU features covering:
>>>
>>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted);
>>> (2) Core topology/neighborhood information and;
>>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient
>>> on non-transactional processors.
>>>
>>> My understanding of the result of this effort was that Oracle JVM
>>> engineers
>>> didn't think they had resources to do this for jdk9. It didn't occur to
>>> me that non-Oracle contributors might want to cherry-pick one (some
>>> of (1) above). It seems plausible to do this, but only if designed
>>> as the first of some possible enhanced support along these lines.
>>>
>> Good point. But that's what an actual community is about. Isn't it?
>>
>> We (Azul) are volunteering the resources for spinloopHint(). Including
>> experimentation, implementation, testing, and even a TCK (which in this
>> case
>> will be trivial). So the vast majority of resources needed will not be
>> coming
>> other budgeted jdk9 resources.
>>
>> I certainly recognize that there will still be work involved that others
>> will
>> end up having to do: reviewing, arguing, contributing opinions, etc., as
>> well
>> as integrating the work into the whole. But this specific proposed JEP is
>> about
>> as narrow and low risk as you can get. especially from a specification
>> point of
>> view (e.g. intrinsic implementation can be left under a flag if deemed
>> risky to
>> stability or schedule).
>>
>> As for fitting in with larger-picture or theme things (listed above). I
>> think that
>> agonizing over the choice of where to put this is important (e.g. the
>> Thread.spinLoopHint()
>> idea, or a create new class that other hints will go into in the future,
>> and where?).
>> But I don't think that there is good reason to bundle this work with e.g.
>> 2CAS, HTM,
>> and affinity. Work. While we can think of them all as "support for recent
>> CPU features",
>> they are very different (and probably have multiple other unrelated
>> groupings).
>>
>> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier
>> discussion
>> on the thread). So does a discussion about a capturing abstraction like
>> synchronic
>> (raised in concurrency interest), But given the actual common uses
>> already waiting
>> for a spinLoopHint(), the very tangible and immediate benefit it shows,
>> and the fact that
>> most of the use cases wouldn't be able to make use of MWAIT (or the
>> like), and some
>> won't be able to use a synchronic-like thing, I think that either a
>> spin-hint-only JEP
>> is not just a good "shortcut", but also an actual stand-alone feature
>> need.
>>
>>
> 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.
>
> If the hint started out as a JDK-specific API, there would be (some) more
> room to modify or drop the API in the future, leaving open the possibility
> of migrating the functionality to the Java SE API too.
>
> -Joe
>

-- 
*The information contained in or attached to this email is strictly 
confidential. If you are not the intended recipient, please notify us 
immediately by telephone and return the message to us.*