Summit comment on interference between hot vs. cold code
John.Rose at Sun.COM
Fri Sep 18 10:50:14 PDT 2009
This just came up during Q&A on Christian Wimmer's talk http://wiki.jvmlangsummit.com/Trace-based_JIT
, and I want to capture it in this forum.
Library writers (like Martin Buchholz) do not want to be burdened with
factoring (sequestering) cold from hot code in order to get good
optimization. Trace-based compilation sifts input code naturally.
A root cause in Hotspot of the interference between cold and hot code
(besides whole-method compilation per se) is the poor metrics we use
for inlining. In particular, we fail to inline a method if it look
too large (in absolute bytecode count) even if most of its bytecodes
are never executed.
Now that we have a bytecode summarization mechanism (for escape
analysis) perhaps we could measure inline candidates more accurately,
by counting their "weight" only according to actually executed (or
frequently executed) bytecodes.
Also, once a whole method is being compiled, we should be
corresponding more eager to inline from hot call sites than from cold
More information about the hotspot-compiler-dev