Summit comment on interference between hot vs. cold code

[John Rose]

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  
ones.

-- John