> 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. Kresten On Apr 4, 5:34 pm, Charles Oliver Nutter <[email protected]> wrote: > 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.
