On Aug 9, 2011, at 12:02 PM, Charles Oliver Nutter wrote: > On Tue, Aug 9, 2011 at 2:31 PM, Charles Oliver Nutter > <head...@headius.com> wrote: >> On Tue, Aug 9, 2011 at 4:30 AM, Christian Thalinger >> <christian.thalin...@oracle.com> wrote: >>> Hmm. I remember you were saying this is some old Ultra 20. The only box I >>> could find which is similar is a 2.0GHz Quad-core Opteron running Solaris >>> and I can't confirm your numbers. >> >> Hmm, interesting. I'll give it another shot today. There certainly >> could have been a goofy build for that first "both patches" attempt. > > Same result with a clean build... > > * hg revert --all > * apply Tom's patch > * fix GCC warning/error > * apply Christian's patch > * ignore the one bad merge (Christian said it's dead code) > * make product ; make create_jdk > > 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? 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. tom > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev