On Mon, Apr 4, 2011 at 9:46 AM, Jochen Theodorou <[email protected]> wrote: >> public static void doSomething(MyInterface x, Object[] args) { >> x.call(args) //C_1 >> } >> public static void doSomethingSmall(){...} >> MyInterface mi = new MyInterface() { >> public void call(Object[] args) { >> doSomethingSmall() //C_2 >> } >> } >> doSomething(mi) //C_3 > > doSomethingSmall in callsite C_2 will be inlined. C_1 is megamorphic > (because called from many other places in many variations), so no inlining. > But C_3 could maybe. I don't know if the megamorphic C_2 taints C_3, or if > that does not matter at all... no idea. > > What I assume is that the JVM has a kind of global concept of a callsite > being megamorphic or monomorphic. Even if C_3 would be inlined it would not > help C_2.
Speaking from what I know of Hotspot... C_2 and C_3 will both likely inline their respective targets. They're not a virtual calls, and they're small. C_1 will inline if only one or two unique types are provided to the doSomething method (Hotspot can inline monomorphic and bimorphic call sites, I believe). If a new type later comes in, the code will be deoptimized and the inlining reversed. Note that another of my "bugs" comes into play here: even if multiple types implement MyInterface and share the same implementation code, Hotspot will consider them separate types for profiling purposes, and as a result even if you only ever have one implementation of "call" in the system, you still might not get it to inline. I'd love to see that fixed :) > If - and I am being crazy here I guess, because I talk about things I > essentially have no idea of - if C_3 is inlined doesn't that make C_1 kind > of monomorphic in a local sense? Wouldn't that mean that if at C_3 is > inlined we can inline at C_2 and C_1 as well? Isn't that exactly what we > would need the JVM doing for "generalized code that calls code"? Wouldn't > that mean that if the JVM means a megamorphic hot call site that there could > be maybe a transformation making it partially monomorphic by isolating part > of the call graph? Wouldn't that be a strategy the JVM could implement in > general, without special marker? Or does the JVM do this already? Again speaking from my non-expert understanding of Hotspot: 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". This problem is actually rampant in JRuby (and probably Groovy too) since we both call through generic pieces of code (e.g. our own call site logic or dispatchers) that see dozens or hundreds of different targets. It's the problem Cliff Click pointed out at the first JVMLS when he profiled JRuby on Azul...our CachingCallSite, while reducing call costs significantly, was preventing target methods from inlining into callers. If I remember right, he described as a solution that you'd have to be able to do repeat passes of type profiling, inlining, type-profiling, inlining...to allow inlined results to themselves be subject to a profiling pass. Hotspot does not do this. I do not know about JRockit or J9, but I suspect that tiered compilers may be able to implement this optimization more easily (since they can instrument inlined code and re-optimize it based on that information). - 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.
