Odd inlining failure

[Roland Westrelin]

Hi Vitaly,

> 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:
> a()
> ------> 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?

Roland.