HotSpot does not inline every call. Which properties of the call site and of the target method decide the outcome, and what practical size and depth limits apply?

## The inliner's two questions For each call site the compiler decides (1) *can* it inline — is there exactly one method body this site will execute, and is that body available and compilable — and (2) *should* it — is the expected benefit worth the code growth and compile time. ## Can it: binding Calls compiled from `invokestatic`, `invokespecial` (constructors, private methods, super calls) have exactly one target by construction. Virtual and interface calls need help: class-hierarchy analysis may show only one loaded implementation, or the recorded receiver-type profile may show one dominant type that the compiler then speculates on behind a class-check guard. If the site has seen many types, the inliner reports `no static binding` and emits a dispatching call. Native methods and methods marked not-compilable are also refused. ## Should it: size bands HotSpot measures callee size in **bytecodes**, not source lines: - **Trivial** — up to `MaxTrivialSize` (6 bytes): accessors and the like, inlined essentially always. - **Small** — up to `MaxInlineSize` (35 bytes by default): inlined even at call sites that are not hot. - **Hot** — up to `FreqInlineSize` (325 bytes): inlined only when the profile shows the site is frequently executed. - **Too big** — beyond that, refused with `too big` / `hot method too big`. A separate ceiling, `DontCompileHugeMethods` with `HugeMethodLimit` (8000 bytecodes), stops the JIT from compiling a monster method at all — it stays interpreted, which is dramatically worse than merely not being inlined. Generated code, giant switch statements, and hand-unrolled loops are the usual victims. ## Should it: depth and budget `MaxInlineLevel` (15 in current HotSpot) bounds how deep a chain of nested inlines may go, so a pipeline of many thin wrappers can run out of depth before reaching the code that matters. Recursive inlining has its own small bound. `InlineSmallCode` refuses to inline a callee whose previously compiled machine code exceeds a threshold, on the theory that it is big in practice regardless of bytecode size. C2 also tracks overall node growth for the compilation and stops expanding when the compilation is getting too large. ## Profile quality matters as much as size An inlining decision is only as good as the profile behind it. If a shared helper method is invoked from many places with many receiver types, its own inner call sites accumulate a polluted profile; a caller that would have been monomorphic in isolation inherits a megamorphic-looking profile and loses inlining. This is why duplicating a small helper occasionally produces a large, surprising speed-up. ## Reading the decisions `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` prints one line per call site with the reason: `inline (hot)`, `accessor`, `too big`, `callee is too large`, `no static binding`, `recursive inlining is too deep`, `not compilable`, `already compiled into a big method`. `-XX:+LogCompilation` gives the same data as XML for tooling. ## What to do with this Tune flags last, structure first. Split huge methods so the hot core is small enough to be inlined and compiled; keep the hot inner loop's dispatch monomorphic; avoid deep towers of trivial wrappers on the hottest path; and confirm with `PrintInlining` rather than assuming. Raising `MaxInlineSize` or `FreqInlineSize` globally usually trades a local win for longer compiles, more code cache and worse instruction locality.