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

[Igor Veresov]

That looks good to me.

igor

> On Feb 11, 2016, at 3:55 PM, Ivan Krylov <ivan at azulsystems.com> wrote:
> 
> Hi Igor,
> 
> Thanks both for your help and your reviews.
> Here is a new version, tested on mac for c1 and c2:
> 
> http://cr.openjdk.java.net/~ikrylov/8147844.hs.03
> 
> Thanks,
> 
> Ivan
> 
> 
> On 11/02/2016 09:51, Igor Veresov wrote:
>> The C2 part looks good to me. Thanks for making the changes.
>> 
>> As for C1…
>> 1. There is already an HIR node to model intrinsics (“Intrinsic”), so unless there is a compelling reason to introduce a new node type I would just use that. That should get rid of many changes to HIR visitors, etc. Follow the existing examples, look for example at how vmIntrinsics::_fullFence works, your case should be the same.
>> 2. It’d be nice to minimize the platform specific changes. There is Compiler::is_intrinsic_supported() method that determines if something should be intensified. Follow the existing examples and add “static bool supports_spin_wait() { return false; }" to Abstract_VM_Version, overload it to true in the VM_Version for x86, then use it to determine whether to intensify the call. You’ll still need a LIR instruction and the LIR_Assembler::on_spin_wait() method, but you can define it on on x86 only. It’s ok to not define a method if you don’t use it, and you won’t, because the intrinsic will be used only on x86.
>> 
>> igor
>> 
>>> On Feb 10, 2016, at 3:47 PM, Ivan Krylov <ivan at azulsystems.com> wrote:
>>> 
>>> I have prepared a new webrev:
>>> http://cr.openjdk.java.net/~ikrylov/8147844.hs.02/
>>> 
>>> Hopefully it addresses the comments that were said before.
>>> Per Vladimir's suggestion I added the c1 intrinsic.
>>> I could not test non-x86 platforms but hopefully nothing is broken there.
>>> 
>>> Thanks,
>>> 
>>> Ivan
>