Good news, bad news

[Rémi Forax]

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.rodriguez at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev