Summit comment on interference between hot vs. cold code

John Rose 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 
  , 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  

-- John

More information about the hotspot-compiler-dev mailing list