megamorphic lambda prevention

[Alexander Turner]

Duncan,

You do it gain! I worked on the very code you mention a few days ago and
yet I _still_ did not understand what you just said. For the benefit of the
mortals here present - it would be brilliant if you could explain it a
little more :)

Thanks  - AJ :)

On 21 June 2012 12:21, MacGregor, Duncan (GE Energy) <
duncan.macgregor at ge.com> wrote:

> Yes, it is very easy for those sites to become megamorphic. We work round
> this by using exactInvokers on function invocation call sites, and caching
> on the method type of the functions rather than the types.
>
> On 21/06/2012 11:37, "Jochen Theodorou" <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
> >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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120621/33f85333/attachment-0001.html