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

[Ivan Krylov]

Looks like there was some good discussion while I was peacefully sleeping.
I don't have much to add. This patch was somewhat inspired by JEP-171 
changes.
Perhaps,there are other ways to achieve the same semantics.

So, if we can consider this reviewed - I will wait for the actual JEP to 
become targeted to 9 and then seek a sponsor to do the push.

Thanks,

Ivan

On 27/01/2016 09:12, Igor Veresov wrote:
> I realize it’s not a big deal. I was just wondering if there was any 
> specific reason control alone is not enough.
> Anyways, looks ok for the first cut.
>
> igor
>
>> On Jan 26, 2016, at 9:24 PM, Gil Tene <gil at azul.com 
>> <mailto:gil at azul.com>> wrote:
>>
>> 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 
>>> <mailto: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. 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/
>>>>
>>>> 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
>>>> Webrev: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
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160127/bd873f62/attachment-0001.html>