again on megamorphic problems

[Jochen Theodorou]

ok, but what would a a more generic linkage in this case here?

Actually... maybe I am wrong with seeing bar as megamorphic in terms of 
indy. In the shown case it is most probably enough to not to test the 
argument at all, since the receiver has an Object parameter and is not 
overloaded. I won't get into the trouble of having to call another bar, 
so it is pretty save. And if I don't need to change the call site target 
I won't need to worry about megamorphic trouble, right?

bye Jochen

Am 20.12.2012 14:32, schrieb Attila Szegedi:
> 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 <blackdrag at gmx.org
> <mailto:blackdrag at 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 at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org