h3. Performance techniques used in the Hotspot JVM
{excerpt}
Methods are often inlined, widening the compiler's "horizon" of optimization.
{excerpt}
_TO DO:_ Pull in content from the following sources:
* http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2008-April/000134.html
* http://forum.java.sun.com/thread.jspa?threadID=790229
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316156
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6565458
* http://blogs.sun.com/watt/resource/jvm-options-list.html
h4. Heuristics
* _TO DO..._
* _Source code:_ http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/share/vm/opto/bytecodeInfo.cpp
h4. Phasing
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.
h4. Profiling
Hot methods are more likely to be inlined... _(Say on...)_
h4. 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.
{excerpt}
Methods are often inlined, widening the compiler's "horizon" of optimization.
{excerpt}
_TO DO:_ Pull in content from the following sources:
* http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2008-April/000134.html
* http://forum.java.sun.com/thread.jspa?threadID=790229
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316156
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6565458
* http://blogs.sun.com/watt/resource/jvm-options-list.html
h4. Heuristics
* _TO DO..._
* _Source code:_ http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/share/vm/opto/bytecodeInfo.cpp
h4. Phasing
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.
h4. Profiling
Hot methods are more likely to be inlined... _(Say on...)_
h4. 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.