Push invalidation + bimorphic fix

[Charles Oliver Nutter]

On Tue, Aug 9, 2011 at 2:43 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>> Same numbers. Is there some other patch you have applied locally?
>> What's the best way for me to investigate?
>
> Can you collect PrintCompilation/PrintInlining output for each of these?

I shall, if I can reproduce it again. I've moved on to Christian's
combined patch (which includes yours) and performance now exceeds all
previous attempts.

> One thing I've seen with the frequency fix is that it that sometimes jruby produces GWTs with the direction reversed from that I expect, so that the invokeFallback path ends up being considered the frequency path.  This can cause us not to inline the fast paths in these cases.  I think we're going to have to add per GWT path profiling sooner rather than later.

I have made some improvements recently that might have fixed that.
JRuby originally invalidated call sites if the associated class's
serial number changed. However, this meant that if after code started
executing, a few methods were added high in the class hierarchy (like
at Object), every call site already encountered would invalidate and
potentially start failing over to slow paths unnecessarily. In
addition, when an interpreted method jitted the associated class's
serial number was also updated, so normal execution could cause all
sites to invalidate again.

I changed the logic as follows:

* If we encounter a new type at a call site and have not exceeded our
GWT cascade limit, we add it to the chain.
* If we exceed the limit of GWT chaining, wipe out the site and switch
it permanently to an inline cache
* If we encounter a type we've seen before but the serial number has
changed, wipe out the site and start over again. This assumes that
most class hierarchy modifications happen early, and if we're still
seeing them we should consider the sites as fluxxy.

Now it's also possible that what you're seeing is the "normal"
PIC-like chaining of GWTs. If a call site first encounters type A, and
later type B, JRuby will add a new GWT for B that falls back on the
GWT for A. If A then turns out to be more common, the fallback path
will fire more often. I think this will be a common pattern for
dynamic languages on the JVM (and potentially for static languages
that have peculiar type structures, like Scala's structural typing),
so being able to promote *either* branch of any particular GWT will
probably be necessary.

- Charlie