Charles, why do you use IRubyObject exactly ? why not using Object instead ?
I use Object in PHP.reboot and see no problem. Rémi On 05/26/2011 09:15 AM, Charles Oliver Nutter wrote: > On Thu, May 26, 2011 at 1:58 AM, Tom Rodriguez<tom.rodrig...@oracle.com> > wrote: >> but test is some ugly goo because of boxing. It's relatively easy to get >> the optimizer to fold away the boxing for boolean but sadly it doesn't help >> the performance at all. Additionally that ends up touching a fair amount of >> common code which makes it a little more risky for 7. > It is definitely frustrating to see that perf has degraded so much the > past couple weeks and still not be there with the reverted code. I'm > hoping your fix will help bring the promised ricochet perf to JRuby, > but so far we're a long way off from what perf looked like on earlier > builds. There must be something more obvious than boolean box > folding...perhaps obvious enough we're not seeing it yet. > >> One oddity I've noticed is that what we're ending up with lots of checkcasts >> to IRubyObject but the optimizer doesn't eliminate redundant ones, probably >> because it's a checkcast to an interface. > IRubyObject is a continuing thorn in my side, it seems! I know there's > an outstanding issue where Hotspot won't see two IRubyObject > implementers that share the same implementation of a given method and > inline that method for both of them. It's not seeing through the > differing types to know that the method body is the same. I wonder if > something like that could be at play here? Too many IRubyObject > implementers through the same logic, so it doesn't ever eliminate the > casts? > >>> Great to hear this is in! I'll look for an MLVM patch and until then >>> see if I can figure out why the "classic" GWT logic isn't as fast as >>> it was a couple weeks ago. IF I'm feeling saucy I may try to pull MLVM >>> + bsd-port from two weeks ago (or find a macosx port build from that >>> timeframe) to compare assembly output. Perhaps illustrative for us >>> all! >> I think that would be informative. > It shall be done! > > - 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
