On 06/05/2011 10:41 AM, Charles Oliver Nutter wrote: > On Fri, Jun 3, 2011 at 1:01 PM, Tom Rodriguez<tom.rodrig...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
