On Tue, Aug 9, 2011 at 2:43 PM, Tom Rodriguez <tom.rodrig...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
