Odd inlining failure
rwestrel at redhat.com
Wed Sep 28 13:03:40 UTC 2016
> I'm trying to understand some "odd" inlining output from PrintInlining -
> hoping someone can explain/confirm.
You could run with -XX:+PrintMethodData (diagnostic). It prints all
profile data at the end of the execution of the VM. You can then look at
invocation counts at the call site of c in b and b in a.
> I have the following call graph:
> ------> b()
> --------------> c()
> So a() calls b() (and some other methods that aren't relevant here). b()
> calls c() and d() internally. a() gets hot, and is queued up for
> compilation (C2, tiered is disabled).
> b() is large (> MaxInlineSize) but less than FreqInlineSize - it gets
> inlined with "inline (hot)" in the log. c() is similar -- it's large, but
> < FreqInlineSize. However, the inlining output says "too big", and c()
> isn't inlined. Now, c() is *always* called when b() is called - it's a
> helper method (ironically, contains code moved out of b() to make b()
> smaller). b() is also the only caller of c().
> So, if b() is "hot", why is c() not? Is it because compilation, and
> therefore inlining, started top-down here? CompileThreshold is the default
> here - 10000. Is it the case that b() reaches 10k, but c() is at 9999
> still and is therefore not inlined?
Maybe b() gets compiled early which would mean we stop collecting
profile data at the call site for c() in b()? Is there a loop in b()
that would cause it be compiled before it's invoked 10k times?
More information about the hotspot-compiler-dev