Implicit null-check in hot-loop?

Vitaly Davidovich vitalyd at gmail.com
Wed May 27 11:39:48 UTC 2015


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/dc8be94b/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list