Jitted array-length checks before entering a loop

Vitaly Davidovich vitalyd at gmail.com
Fri Oct 9 18:51:40 UTC 2015


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)        #
                                                ;   {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}
                                                ;   {runtime_call}
  0x00007f63476c7e0c: callq  0x00007f634c17f570  ;*aload_0
                                                ;   {runtime_call}
  0x00007f63476c7e11: mov    $0xfffffff6,%esi
  0x00007f63476c7e16: nop
  0x00007f63476c7e17: callq  0x00007f6347684320  ; OopMap{off=124}
                                                ;   {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/20151009/7bf55dcb/attachment.html>

More information about the hotspot-compiler-dev mailing list