search

AdoptOpenJDK / jitwatch

Log analyser / visualiser for Java HotSpot JIT compiler. Inspect inlining decisions, hot methods, bytecode, and assembly. View results in the JavaFX user interface.
Other
3.06k stars 437 forks source link

Assembly viewer - inlined ASM missing? #290

Closed toaler closed 5 years ago

toaler commented 5 years ago

I've been using JITWatch to understand how to discover JIT opportunties and so far it's been a great tool. My question pertains to the assembly view and inlined ASM.

I have a method testBigMethod that calls bigMethod. Using FreqInlineSize I was able to get bigMethod inlined into the caller testBigMethod.

Using JitWatch confirms this via the call chain view as well as the bytecode view invokespecial high lighted as green. So i'm 100% sure the inlining of bigMethod in testBigMethod is occuring.

Naively, I was expecting the asm for bigMethod to show up in the assembly view, but to my surprise I can't see it nor any obvious reasons as to why it's not there. Is this by design? I'm looking for details as why it's not there. Screenshot of what i'm seeing below.

screen shot 2018-09-11 at 9 57 08 pm

Thanks in advance,

chriswhocodes commented 5 years ago

Hi Brian, I see you're using JMH which processes the benchmarking annotations to produce the final bytecode that includes the test loops etc. I see from the screenshot that the class and method names don't appear to be mangled (I think JMH produces synthetic method names). Is there any chance you could send me the source / hotspot log file and I'll investigate? Thanks, Chris

toaler commented 5 years ago

I think JMH generates various classes that eventually call down to bench.jit.InliningTest.testBigMethod to avoid DCE and other jit optimizations from happening. Here's what you asked for.

InliningTest.java.zip

hotspot_pid94018.log.zip

toaler commented 5 years ago

@chriswhocodes let me know if you need anything else. I can see that bench.jit.InlingTest.bigMethod is being inlined (call chain and bytecode pane of triview are green) into bench.jit.InliningTest.testBigMethod. I just don't get why I don't see the ASM for bigMethod inlined in testBigMethod assembly.

shipilev commented 5 years ago

@toaler I think you need to say: 

  public long testBigMethod() {
    return bigMethod(1, 1);
  }

to actually avoid DCE. Stands to reason there is no generated code for the method otherwise -- it was optimized away. See JMHSample_08_DeadCode.

chriswhocodes commented 5 years ago

Hi Brian, I've run your test class and I get the same result: jitwatch-snapshot-2018 09 19 22 38 45 with TriView: triview-snapshot-2018 09 19 22 38 53 where you can see no assembly from bigMethod(). I thought this might be because the inlined method body had been eliminated due to DCE because the result of bigMethod() is not used.

chriswhocodes commented 5 years ago

When I change your testBigMethod() code to return the result of the call to bigMethod() I get this triview-snapshot-2018 09 19 22 51 46 If you look at the line mov $0xe, eax you will see the result of your calculations (return 14) so the compiler has done a good job of reducing your call to bigMethod(1, 1) to a constant return of 14 (0xe in hex). Hope this helps? If you throw in a java.util.Random then the calc will be less reducible and easier to spot the inlined assembly :)