Suboptimal C2 code generation

[Vitaly Davidovich]

Hi John,

Vladimir already answered your question (I think), but now that I'm at the
computer again, here's the rest of the instruction stream covering the two
jump addresses when type checks fail:

  0x00007ff5f82e00e4: jmp    0x00007ff5f82e00c5
*  0x00007ff5f82e00e6: mov    $0xffffffde,%esi*
  0x00007ff5f82e00eb: mov    %r11d,(%rsp)
  0x00007ff5f82e00ef: callq  0x00007ff5f8250ee0  ; OopMap{[0]=NarrowOop
off=148}
                                                ;*invokeinterface value2
                                                ;   {runtime_call}
  0x00007ff5f82e00f4: callq  0x00007ff5fce73580  ;*invokeinterface value2
                                                ;   {runtime_call}
*  0x00007ff5f82e00f9*: mov    %rsi,%rbp
  0x00007ff5f82e00fc: mov    %r11d,(%rsp)
  0x00007ff5f82e0100: mov    $0xffffffde,%esi
  0x00007ff5f82e0105: xchg   %ax,%ax
  0x00007ff5f82e0107: callq  0x00007ff5f8250ee0  ; OopMap{rbp=Oop
[0]=NarrowOop off=172}
                                                ;*invokeinterface value
                                                ;   {runtime_call}
  0x00007ff5f82e010c: callq  0x00007ff5fce73580  ;*invokeinterface value
                                                ;   {runtime_call}
  0x00007ff5f82e0111: mov    $0xfffffff6,%esi
  0x00007ff5f82e0116: nop
  0x00007ff5f82e0117: callq  0x00007ff5f8250ee0  ; OopMap{off=188}
                                                ;*invokevirtual value
                                                ;   {runtime_call}
  0x00007ff5f82e011c: callq  0x00007ff5fce73580  ;*invokevirtual value
                                                ;   {runtime_call}

I believe those instruction paths end with a call to the deopt stub.

Thanks


On Thu, Nov 19, 2015 at 9:29 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Nov 19, 2015, at 2:58 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
>         return _w.value() + _w.value2();
>
>
> Which is (ignoring non-taken null branches):
>
>         return _w._i.value() + _w._i.value2();
>
> There are two independent fetches of _w._i in the bytecode.
> The machine code is treating them as independent, where
> we would want the optimizer to use a common value.
>
> The machine code is optimistic that _w._i is always a C,
> but it appears to be leaving open the possibility that some
> activity not tracked by the JIT could store some other C2 <: I.
>
> What happens at 0x00007ff5f82e00f9?  Does it de-opt,
> or does it merge back into 0x00007ff5f82e00b2?  In the
> latter case, the JIT cannot assume that _w._i is a C.
>
> So, it could be a failure to de-opt, or it could be some
> fluff in the IR which is preventing the two _w._i from
> commoning.  Or something else.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151120/0836e8f6/attachment.html>