More performance explorations
Charles Oliver Nutter
headius at headius.com
Sun Jun 5 01:41:16 PDT 2011
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.
- Charlie
More information about the mlvm-dev
mailing list