Implicit null-check in hot-loop?

[Vitaly Davidovich]

Hi Vladimir,

Given java has no unsigned long, wouldn't this be somewhat straightforward
to test? I agree that it's unlikely to be worth it given most loops are int.

Thanks

On Fri, May 29, 2015 at 1:38 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> There is reason. We do long arithmetic to prove that int index will not
> overflow in canonical (counted) loops but we can't do that cheaply for long
> index. And 99% of loops use int index - so we don't want to spend code on
> edge case.
>
> Regards,
> Vladimir
>
>
> On 5/27/15 5:25 AM, Vitaly Davidovich 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
>> <mailto: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
>> <mailto: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
>>> <mailto: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
>>>         <mailto: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
>>> <mailto: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/20150529/5c720060/attachment.html>