More performance explorations

[Rémi Forax]

On 06/05/2011 10:41 AM, Charles Oliver Nutter wrote:
> On Fri, Jun 3, 2011 at 1:01 PM, Tom Rodriguez<tom.rodriguez at oracle.com>  wrote:
>> On Jun 3, 2011, at 12:12 AM, Charles Oliver Nutter wrote:
>>
>>> I did make another small discovery: the + calls never inline
>>> completely. They eventually are a virtual invocation of
>>> RubyFixnum.op_plus, and in both old and new builds they're calls in
>>> the asm.
>> That's not what I see when I run it.  RubyFixnum::op_plus is always inlined in the runs I do.
> Am I reading the dumps wrong. If possible, tell me where you see them
> inlining in the asm dumps I provided against mlvm and macosx builds. I
> want to learn how to better understand the assembly output!
>
>> The current machinery should do the same inlining that it would have done if there were a direct call instead of a method handle invoke.  Basically the call site has frequency information that drives our more aggressive inlining and that is propagated through the method to the final call.  So if the method handle is hot then the final call will be too.
> As Rémi mentioned, the game changes somewhat when the eventual direct
> MH invoke is at the end of a chain of other handles like GWTs and
> argument permutes; or rather...it's at least different than doing a
> MethodHandle.invokeExact in-place myself, and I would just like to
> know whether it's treated any differently by Hotspot.
>
>> Don't get sad just yet.  7 won't perform as well as it might but we should be able to fix the performance issues in the updates.  Once the core implementation is ironed out we can optimize to our hearts content and there no problem getting that into update releases.
> Oh I definitely understand! I have expected for some time that
> performance would be adequate but not stellar for the 1.7.0 release,
> and that after you all had ironed out the compatibility and stability
> issues we'd hit performance hard for an update. At that point, we'll
> be comfortable releaseing a JRuby version that's invokedynamic-based,
> since the numbers will better reflect what we all want them to.

7 already performs well.
But yes, compared to a top notch JVM based dynamic language runtime,
7 has some performance glitches.

But please don't forget that implementing a runtime with invokedynamic
is a way easier that to write one without it.

Also invokedynamic performance is already stellar if you have primitive 
types
in the signature compared to other runtimes.
By example, for JRuby,  x + 1 can have a dedicated fast path that:
   - doesn't require to box 1 to a Fixnum.
   - has a specific overflow check.
This kind of optimization is hard to implement without invokedynamic.

> - Charlie

Rémi