Implicit null-check in hot-loop?

[Vitaly Davidovich]

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/5e02c092/attachment.html>