Unusually high polymorphic dispatch costs?

[Rémi Forax]

On 04/30/2011 11:13 PM, Charles Oliver Nutter wrote:
> Well it seems like the GWT-based PIC could be a *great* success, at
> least compared to falling back on a single-entry IC. I will shortly
> commit another patch to JRuby master that provides a configurable GWT
> chain size before giving up and going to a simple IC, and the results
> are spectacular.
>
> First, recall that my little bimorphic bench took 9s to run when
> constantly rebinding. GWT construction is expensive, CallSite
> rebinding is expensive...we've clearly established that.
>
> JRuby with an immediate failover to a simple IC performs roughly like
> JRuby, with each million-cycle iteration taking about 0.13s, a massive
> improvement over rebinding. No real surprise there, since it's
> essentially just giving up and doing the same thing as JRuby's
> CachingCallSite.
>
> Now for the surprise. With a 2-deep GWT chain simulating a PIC, the
> bimorphic benchmark performs almost *identically* to one that's
> monomorphic. The iterations take roughly 0.054s when monomorphic and
> 0.056s when bimorphic.

I remember seeing a patch from John to group
a cascade of typechecks on the same object into one check.

>   If it goes trimorphic, the hard failure kicks
> in and it drops back to IC performance again.
>
> Naturally I'm quite pleased by this result.
>
> For those of you following along at home, the commit is 9890000 and
> the property to configure is jruby.invokedynamic.maxfail, which should
> equal the number of GWT it will attempt to chain before failing over
> to simple IC.
>
> Awesome stuff.

Also, instead of using IC has a fallback, you can use a hashmap
to handle megamorphic calls that are not mega-megamorphic.

> - Charlie

cheers,
Rémi