again on megamorphic problems

[Charles Oliver Nutter]

On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou <blackdrag at 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