RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic

[Gil Tene]

Since a sensical loop that calls onSpinWait() would include at least a volatile load on every iteration (and possibly a volatile store), the new node does not create significant extra move restrictions that are not already there. Modeling this with a memory effect is one simple way to prevent it from being re-ordered out of the loop. There are probably other ways to achieve this, but this one doesn't really have a performance downside…

— Gil.

> On Jan 26, 2016, at 4:44 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> So, why does the new node have a memory effect? That would seem to prevent any movement of the subsequent loads in your loop, right? If that’s intentional I wonder why is that?
> 
> igor
> 
>> On Jan 26, 2016, at 2:59 AM, Ivan Krylov <ivan at azulsystems.com <mailto:ivan at azulsystems.com>> wrote:
>> 
>> Hello,
>> 
>> Some of you may have a seen a few e-mails on the core-libs alias about a proposed “spin wait hint”. The JEP is forming up nicely at  https://bugs.openjdk.java.net/browse/JDK-8147832 <https://bugs.openjdk.java.net/browse/JDK-8147832>. There seems to be a consensus on the API side. It is now in a draft state and I hope this JEP will get targeted for java 9 shortly.  The upcoming API changes can be seen at the webrev:
>> http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ <http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/>
>> 
>> At this time I would like to ask for a review of the hs-comp changes. The plan is push changes into class libraries and hotspot synchronously but that may happen after the JEP gets targeted.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147844 <https://bugs.openjdk.java.net/browse/JDK-8147844>
>> Webrev: http://cr.openjdk.java.net/~ikrylov/8147844.hs.00/ <http://cr.openjdk.java.net/~ikrylov/8147844.hs.00/>
>> 
>> The idea of the fix is pretty simple: hotspot replaces a call to java.lang.Runtime.onSpinWait() with an intrinsic that is effectively a 'pause' instruction on x86.  This intrinsic is guarded by the -XX:±UseOnSpinWaitIntrinsic flag. For non-x86 platforms there is a verification code that makes sure the flag is off, VM will just execute at empty method java.lang.Runtime.onSpinWait() – effectively a no-op. According the [1] the 'pause' instruction is functional since SSE2, but even on CPUs prior to SSE2 the  'pause' instruction is a no-op and hence harmless, there seems to be no need to add guarding code for older generations of Intel CPUs.
>> 
>> The proposed patch includes a simple regression test that simply makes sure that method java.lang.Runtime.onSpinWait() gets intrinsified.  There are several other producer-consumer-like performance tests ready that the authors of this JEP would be happy to make available under JEP-230 but I am uncertain about the process.
>> 
>> Thanks,
>> 
>> Ivan
>> 
>> [1]  - https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops <https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160127/1ef62b39/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160127/1ef62b39/signature-0001.asc>