Implicit null-check in hot-loop?

[Vitaly Davidovich]

Also, my hunch is that loop unrolling in current production hotspot isn't
necessarily a win for long trip counts since there's virtually no
vectorization and I'm not sure making the loop code bigger is a net win
since OoO CPUs can take care of them well on their own.
Eliminating/reducing the safepoint check is probably the biggest win.

sent from my phone
On May 27, 2015 8:27 AM, "Benedikt Wedenik" <
benedikt.wedenik at theobroma-systems.com> wrote:

> Okay :)
>
> Thank you again!
>
> Benedikt.
> On 27 May 2015, at 14:25, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> I don't think there's any fundamental reason, it's just that int loops are
> more common and so were optimized.
>
> sent from my phone
> On May 27, 2015 8:09 AM, "Benedikt Wedenik" <
> benedikt.wedenik at theobroma-systems.com> wrote:
>
>> First of all, thanks for your quick response :)
>> You were absolutely right - but I do not understand why the long counter
>> was the problem.
>>
>> Is there any reason why the loop-unrolling is only available for int
>> loops?
>> I mean I guess so - because else it would probably be implemented already.
>> But still it would be a nice opportunity for an optimisation :)
>>
>> Benedikt.
>> On 27 May 2015, at 13:44, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>> Also, the safepoint check on each iteration should go away when using an
>> int loop; it'll be coalesced into once per unroll factor or may go away
>> entirely if the loop turns into a counted loop.
>>
>> sent from my phone
>> On May 27, 2015 7:39 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>>
>>> Cause you're using a long as induction variable; change to int and it
>>> should unroll.
>>>
>>> sent from my phone
>>> On May 27, 2015 6:46 AM, "Benedikt Wedenik" <
>>> benedikt.wedenik at theobroma-systems.com> wrote:
>>>
>>>> Oh!
>>>>
>>>> Thanks :) So then it's not so bad, cause it is (I guess) obligatory.
>>>>
>>>> Do you have any idea why this loop does not get unrolled?
>>>>
>>>> Benedikt.
>>>>
>>>> On 27 May 2015, at 12:36, Andrew Haley <aph at redhat.com> wrote:
>>>>
>>>> > On 05/27/2015 11:27 AM, Benedikt Wedenik wrote:
>>>> >>
>>>> >> In the hot-loop there is this “ldr” which looked a little “strange”
>>>> at the first glance.
>>>> >> I think that this load is a null-check? Is that the case?
>>>> >
>>>> > No.  It's a safepoint check.  HotSpot has to insert one of these
>>>> because
>>>> > it can't prove that the loop is reasonably short-lived.
>>>> >
>>>> >> I also investigated the generated code on x86 which is quite
>>>> similar, but instead of a load, they are
>>>> >> using the “test”-instruction which performs an “and” but only sets
>>>> the flags discarding the result.
>>>> >> Is there any similar instruction available on aarch64 or is this
>>>> already the closest solution?
>>>> >
>>>> > Closest to what?  A load to XZR is the best solution: it does not hit
>>>> > the flags.  x86 cannot do this.
>>>> >
>>>> > It looks like great code.
>>>> >
>>>> > Andrew.
>>>> >
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150527/60ea7657/attachment.html>