On Tue, Apr 5, 2011 at 8:25 AM, Kresten Krab Thorup <[email protected]> wrote: >> Even if C_3 inlines, C_1 remains megamorphic because Hotspot treats it >> as a lone call site independent of calls around it. There's no concept >> of "the C_1 call site when called from C_3". > > That is actually not how I thought HotSpot works; isn't that the whole > point of inlining that the embedded calls can be applied with more > precise information? Strange.... I'm disappointed.
It is disappointing. Cliff Click just posted an entry about this issue, confirming that current JVMs don't do what you hoped they'd do and discussing at least one strategy for solving "The Problem": http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem Long story short...nope, JVMs don't do this right now. Pass a couple functions into an iterator and JVMs won't inline those functions. You're stuck with virtual calls and no visibility across that call boundary to optimize the loop itself. I'm sure this is one of the remaining major bottlenecks in JRuby. When I switch to modes that profile at runtime and insert direct inlinable invocations, JRuby perf improves 2-3x even on benchmarks we used to think were bottlenecking on Fixnum object creation. In fact, I can get JRuby to run nearly as fast as Java itself for equivalent work (i.e. a Java-based Fixnum fibonacci versus a Ruby-based Fixnum fibonacci). If inlining plain method calls has that kind of impact, imagine how much performance we're losing by not being able to inline functions across megamorphic iterator boundaries. For my part, I will probably continue down the road of specializing at the bytecode level, to allow more code to inline (at the cost of more of the inlining budget, unfortunately) and doing runtime optimizations as much as possible. Hopefully the JVMs will catch up to JRuby soon :) - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
