megamorphic lambda prevention

[Alexander Turner]

The simple answer is 'yes it is easy to go megamorphic'. The interesting
question is why does this matter. You already have a complex dispatch
system here and you are calling method off it. The cost of a well coded
megamorphic dispatch system under the covers is not likely to have any
significant impact on over all performance.

The key (from my experience so far) is to ensure that you fall over to mega
morphic dispatch cleanly with out letting fall back chains grow too long
and keep the dispatch system very fast.

- AJ

On 21 June 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120621/2e235491/attachment-0001.html