Good news, bad news

[Christian Thalinger]

On May 26, 2011, at 10:42 AM, Christian Thalinger wrote:
> On May 26, 2011, at 9: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.
> 
> I also did some performance testing.  I used a recent HS repository, applied Tom's patch, used a recent meth.jar provided by John and this is what I got:

<snip>

> Here are the numbers from April 28 on the same machine:
> 
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002873.html
> 
> Although I can't remember if the invokedynamic numbers were with or without the guard-removal-hack I tried at that time (I think without, because with the hack the numbers should be very similar to dynopt, see: http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002869.html).
> 
> Using Tom's new code doesn't make a difference since I think the meth.jar from John includes the reverted GWT code.

I looked at the inlining tree of fib and everything looks good and is inlined.  There is one invokeExact which is:

  @ 43   java.lang.invoke.MethodHandle::invokeExact (42 bytes)   too big

but bumping the MaxInlineSize just shows that it's:

  @ 43   java.lang.invoke.MethodHandle::invokeExact (42 bytes)   call site not reached

so it doesn't matter anyway.

Is there some additional code that got added to the GWT logic or maybe some additional code on the JRuby side that would explain the slowdown?

-- Christian