Can java inline a large method if the most of it would be dead code at the call site?

Question

I know that one of the criteria that Java HotSpot uses to decide whether a method is worth inlining is how large it the method is. On one hand, this seems sensible: if the method is large, in-lining leads to code bloat and the method would take so long to execute that the call overhead is trivial. The trouble with this logic is that it might turn out that AFTER you decide to inline, it becomes clear that for this particular call-site, most of the method is dead code. For instance, the method may be a giant switch statement, but most call sites call the method with a compile-time constant, so that actually: in-lining is cheap (don't need whole method body; minimal code bloat) and effective (method call overhead dominates actual work done).

Does HotSpot have any mechanism to take advantage of such situations and inline the method anyway, or is there a limit beyond which it refuses to even consider inlining a method, even though it would have a minimal code bloat effect?

Answer 1

HotSpot JIT inlining policy is rather complicated. It involves many heuristics like caller method size, callee method size, IR node count, inlining depth, invocation count, call site count etc.

There are some hard limits that prevent a large method from inlining, including:

• -XX:FreqInlineSize=325 - the maximum size in bytecodes of the callee to be inlined;
• -XX:InlineSmallCode=2000 - do not inline the callee if it already has a compiled code of at least this size in bytes;
• -XX:NodeCountInliningCutoff=18000 - stop inlining if parser generates this number of IR nodes;
• -XX:DesiredMethodLimit=8000 - the maximum size in bytecodes of aggregate method after inlining. This parameter is not tunable in product builds of HotSpot, but the limit can be switched off with -XX:-ClipInlining.

There are also other limits, but as you already see, a large method does not have much chance to be inlined, even though -XX:+IncrementalInline is enabled by default.