megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 01:57 PM, Krystal Mok wrote:
> That's "the inlining problem" that Cliff Click was talking about [1], 
> right?

yes,

>
> I wonder how well the new interpreter design in Graal would handle 
> this kind of case, since it's supposed to have picked the good parts 
> from trace-based compilation, but without actually having to do 
> tracing. Can't wait to see more details of it at this year's JVM 
> Language Summit.

I spend a couple of days in Linz last month with the Autrian part of the 
Graal team (Thomas, Lukas and Gilles)
and we discuss about this issue (among other things).
I think we should book a room during the Summit to try to see if 
something can be done in Hotspot.

>
> - Kris

Rémi

>
> [1]: 
> http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem 
>
>
> On Thu, Jun 21, 2012 at 6:37 PM, Jochen Theodorou <blackdrag at gmx.org 
> <mailto:blackdrag at gmx.org>> wrote:
>
>     Hi all,
>
>     I was wondering... if I have code like this:
>
>     list.each { x -> foo(x) }
>     list.each { x -> bar(x) }
>     list.each { x -> something(x) }
>
>     then isn't it the a case where within the each method we easily get
>     something megamorphic, since there are too many different kinds of
>     lambdas involved? Isn't that a general problem with internal iterators
>     and is there any plan to enhance hotspot to counter that problem?
>
>     bye Jochen
>
>     --
>     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
>
>     _______________________________________________
>     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
>
>