...
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.
Profiling
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.
- ''Future:'' Extend the oracle to include profiling information collected from earlier runs, or generated by an offline configuration tool.