Jitted array-length checks before entering a loop
Vitaly Davidovich
vitalyd at gmail.com
Tue Oct 27 00:58:58 UTC 2015
Anyone have thoughts?
sent from my phone
On Oct 16, 2015 10:56 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
> Chris (or anyone else),
>
> Any thoughts on this? Looks like an opportunity to slim down the emitted
> code.
>
> Thanks
>
> On Fri, Oct 9, 2015 at 4:14 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> So basically, the deopt blobs are unreachable -- not sure if that's
>> intentional or not. Perhaps it's intentional in that deopt'ing in this
>> case is a waste of time (the simple exit is just fine), but the code for it
>> is left behind.
>>
>> On Fri, Oct 9, 2015 at 2:51 PM, Vitaly Davidovich <vitalyd at gmail.com>
>> wrote:
>>
>>> Chris,
>>>
>>> Below is a sample dump (array is in %rsi). You can see the 2 tests in
>>> question that jump to deopt blobs (I presume). If I change the code to
>>> always pass a zero length array (the below assembly is for non-empty array
>>> 100% of the time), the code generation changes to favor that case, and
>>> these tests are not present.
>>>
>>> 0x00007f63476c7da0: mov %eax,-0x14000(%rsp)
>>> 0x00007f63476c7da7: push %rbp
>>> 0x00007f63476c7da8: sub $0x10,%rsp ;*synchronization entry
>>>
>>> 0x00007f63476c7dac: mov 0xc(%rsi),%r10d ;*arraylength
>>>
>>> ; implicit exception:
>>> dispatches to 0x00007f63476c7e11
>>> 0x00007f63476c7db0: test %r10d,%r10d
>>> 0x00007f63476c7db3: jle 0x00007f63476c7de2 ;*if_icmplt
>>>
>>> 0x00007f63476c7db5: test %r10d,%r10d
>>> 0x00007f63476c7db8: jbe 0x00007f63476c7dfd
>>> 0x00007f63476c7dba: mov %r10d,%r8d
>>> 0x00007f63476c7dbd: dec %r8d
>>> 0x00007f63476c7dc0: cmp %r10d,%r8d
>>> 0x00007f63476c7dc3: jae 0x00007f63476c7dfd
>>> 0x00007f63476c7dc5: xor %r11d,%r11d
>>> 0x00007f63476c7dc8: nopl 0x0(%rax,%rax,1) ;*aload_0
>>>
>>> 0x00007f63476c7dd0: mov 0x10(%rsi,%r11,4),%r8d ;*aaload
>>>
>>> 0x00007f63476c7dd5: test %r8d,%r8d
>>> 0x00007f63476c7dd8: je 0x00007f63476c7dee ;*invokevirtual amethod
>>>
>>> 0x00007f63476c7dda: inc %r11d ;*iinc
>>>
>>> 0x00007f63476c7ddd: cmp %r10d,%r11d
>>> 0x00007f63476c7de0: jl 0x00007f63476c7dd0 ;*return
>>>
>>> 0x00007f63476c7de2: add $0x10,%rsp
>>> 0x00007f63476c7de6: pop %rbp
>>> 0x00007f63476c7de7: test %eax,0x5cd3213(%rip) #
>>> 0x00007f634d39b000
>>> ; {poll_return}
>>> 0x00007f63476c7ded: retq
>>> 0x00007f63476c7dee: mov $0xfffffff6,%esi
>>> 0x00007f63476c7df3: callq 0x00007f6347684320 ; OopMap{off=88}
>>> ;*invokevirtual amethod
>>> ; {runtime_call}
>>> 0x00007f63476c7df8: callq 0x00007f634c17f570 ;*invokevirtual amethod
>>> ; {runtime_call}
>>> 0x00007f63476c7dfd: mov %rsi,%rbp
>>> 0x00007f63476c7e00: mov $0xffffff86,%esi
>>> 0x00007f63476c7e05: xchg %ax,%ax
>>> 0x00007f63476c7e07: callq 0x00007f6347684320 ; OopMap{rbp=Oop
>>> off=108}
>>> ;*aload_0
>>> ; {runtime_call}
>>> 0x00007f63476c7e0c: callq 0x00007f634c17f570 ;*aload_0
>>> ; {runtime_call}
>>> 0x00007f63476c7e11: mov $0xfffffff6,%esi
>>> 0x00007f63476c7e16: nop
>>> 0x00007f63476c7e17: callq 0x00007f6347684320 ; OopMap{off=124}
>>> ;*arraylength
>>> ; {runtime_call}
>>> 0x00007f63476c7e1c: callq 0x00007f634c17f570 ;*arraylength
>>> ; {runtime_call}
>>>
>>>
>>> On Fri, Oct 9, 2015 at 2:31 PM, Christian Thalinger <
>>> christian.thalinger at oracle.com> wrote:
>>>
>>>>
>>>> On Sep 28, 2015, at 3:37 AM, Nassim Halli <nassim.halli at gmail.com>
>>>> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I have a question relative to some code generated by the C2 compiler.
>>>>
>>>> When I look at the assembly codes for this method:
>>>>
>>>> static void compiledMethod (Atype[] data) {
>>>> int n = data.length
>>>> for (int i = 0; i < n; ++i)
>>>> data[i].amethod();
>>>> }
>>>>
>>>> I get the this assembly on Linux X86_64 before entering the loop (not
>>>> OSR):
>>>>
>>>> # data is in rbx
>>>> mov 0xc(%rbx),%r9d
>>>>
>>>> # data.length is in r9d
>>>> test %r9d,%r9d
>>>> jle END_OF_LOOP
>>>>
>>>> test %r9d,%r9d
>>>> jbe BB0
>>>>
>>>> mov %r9d,%r11d
>>>> dec %r11d
>>>> cmp %r9d,%r11d
>>>> jae BB0
>>>>
>>>>
>>>> Did you leave out any assembly? Where is BB0?
>>>>
>>>>
>>>> It seems to me the second and third check are useless and the
>>>> corresponding branches are never taken.
>>>> Could you please tell me more about these checks, If and why are they
>>>> required ?
>>>>
>>>> Thanks a lot.
>>>>
>>>> Nassim H.
>>>>
>>>>
>>>> *Test conditions:*
>>>>
>>>> java version "1.8.0_51"
>>>> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
>>>> Default options.
>>>> Linux, Intel Sandy Bridge core i5-2000
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151026/e6ed2ff5/attachment.html>
More information about the hotspot-compiler-dev
mailing list