Prerequisites
- Familiarity with JIT terminology: inlining, tiered compilation, deoptimization, monomorphic vs. megamorphic call sites.
Keep hot paths legible to the compiler
Very large methods, unstable call sites, megamorphic dispatch and mixed exceptional behaviour make optimisation harder. The code may still compile, but not necessarily into the shape you expected.
Practical constraints
- separate cold validation and error construction from the hot path,
- keep call sites stable enough for useful profiling feedback,
- avoid accidental interface polymorphism inside tight loops,
- verify inlining and generated code rather than assuming it.
Trade-offs
Splitting cold validation and error paths out of a hot method costs readability: the logic that guards a code path moves away from the code it guards, and a single polymorphic call site sometimes has to become several concrete ones. That cost is only worth paying where profiling shows the JIT is actually failing to do its job on this code — not applied everywhere as a house style.
Measure the generated behaviour
Use JITWatch, compilation logs, perfasm and profiles under representative load. Source code is merely a suggestion submitted to several layers of machinery with opinions of their own.
Evidence and related laboratories
Performance Lab does not yet host a benchmarked reference lab for JIT compilation behaviour, so the guidance above is experience-based rather than measured data on this site. An early, non-reference prototype exploring the compilation pipeline is at /lab/#jit-pipeline, but it predates the interactive framework and isn't held to the same evidentiary bar as the labs in the main catalogue — verify these claims on your own workload with the tools below.
Sources and further reading
- Optimizing Java — Benjamin J Evans, James Gough & Chris Newland, O'Reilly, 2018.
- JITWatch — github.com/AdoptOpenJDK/jitwatch
- HotSpot
-XX:+PrintCompilation/-XX:+PrintInliningdiagnostic options — Oracle HotSpot VM options reference.