On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou <blackd...@gmx.org> wrote:
> let us assume the following example... I have a method foo
>
> public Object foo(Object arg){return bar(arg)}
>
> nothing fancy, quite simple... and let us assume foo is called from
> dozens of places with differing argument types.
>
> If I understood right, then the call site in foo will become
> megamorphic, making it impossible to inline bar into the place from
> where foo is called. foo becomes like a inlining barrier so to say.This is no different than for Java code, of course. > The question is now more or less, if I can avoid that problem with > MethodHandles. I mean the pattern should occur with lamdas more than > once and I am wondering if there is anything planed to do against this > or if there has been already done something, or well, if I can bypass > the problem in indy. It's not a problem in indy, it's just a limitation of how Hotspot inlines. This also impacts any methods that accept a closure as an argument; if there's more than a couple different closures, the callback is megamorphic. The only solution for you (and for Hotspot) is to specialize the foo method on a per-type (argument type, that is) basis, so that the type profile carries all the way through to a unique call target at bar. We are experimenting with that in JRuby, since we usually have the full AST available for every method (so we can emit multiple specialized versions of it). If you can't, then your best bet is just failing the bar call size (in JRuby, we do it if we see more than three types) and forever bind a simple non-indy cache to it (we bind a simple single-element, MRU inline cache). - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
