I will just toot my own horn and say that Dynalink handles this - Nashorn actually leverages this feature to detect megamorphic sites and relink them differently. Dynalink keeps track of number of times a call site is relinked, and if it reaches a configurable threshold [1], it'll start returning true in "isCallSiteUnstable" [2] method in the link requests it sends to the linkers, who are then at a discretion to create different linkage - supposedly something more generic that might be less efficient than any individual narrow linkage, but wins in the end as it's more stable and avoids further relinking.
Attila. [1] https://github.com/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/DynamicLinkerFactory.java#L169 [2] https://github.com/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/linker/LinkRequest.java#L59 On Thu, Dec 20, 2012 at 2:10 PM, Jochen Theodorou <blackd...@gmx.org> wrote: > Hi, > > 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. > > 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. > > bye Jochen > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
