Skip to end of metadata
Go to start of metadata

Performance techniques used in the Hotspot JVM

Methods are often inlined, widening the compiler's "horizon" of optimization.

TO DO: Pull in content from the following sources:



Currently, inlining decisions are performed eagerly (in both C1 and C2), as soon as the parser reaches a call site the first time.

This makes the inlining heuristics less robust, since they must estimate the "heat" of each call site without comparison with call sites not yet encountered. Cold sites are kept out of line, while hot sites are inlined, and recursively parsed immediately. A good project would be to support warm sites (neither hot nor cold), which would be macro-expanded from a priority queue until the estimated frequency drops enough, or the compilation task gets too large.


Hot methods are more likely to be inlined... (Say on...)

Manual advice to the inliner

There are several ways to help the inliner make the decision you want it to:

  • Warm up your code properly.
  • Segregate fast paths from slow paths, keeping hot methods small (35 bytecodes or less) with error processing and slow paths in separate methods.
  • Request inlining from the compiler oracle. (Need a ref.)
  • Future: Find better heuristics and code them into the JVM.
  • Future: Add an @Inline annotation to the JVM. (Needs hacky POC experimentation first.)
  • Future: Extend the oracle to include profiling information collected from earlier runs, or generated by an offline configuration tool.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.