Summit comment on interference between hot vs. cold code

Chuck Rasbold rasbold at google.com
Fri Sep 18 11:37:33 PDT 2009


On Fri, Sep 18, 2009 at 10:50 AM, John Rose <John.Rose at sun.com> wrote:

> 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.
>
>
Can you elaborate on the last statement a little bit?   I don't think I
understand what you mean....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090918/bb7af40d/attachment.html 


More information about the hotspot-compiler-dev mailing list