On Aug 9, 2011, at 12:02 PM, Charles Oliver Nutter wrote: > On Tue, Aug 9, 2011 at 2:31 PM, Charles Oliver Nutter > <[email protected]> wrote: >> On Tue, Aug 9, 2011 at 4:30 AM, Christian Thalinger >> <[email protected]> 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 > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
