More performance explorations
Rémi Forax
forax at univ-mlv.fr
Fri Jun 3 11:58:23 PDT 2011
On 06/03/2011 08:01 PM, Tom Rodriguez 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.
>
>> This makes me wonder if Rémi was right about userland virtual
>> invocations never inlining at the end of a method handle chain. Can
>> that truly be the case? If so, it would mean most of JRuby's core
>> class methods won't inline...a sad state of affairs :(
> 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.
Agree if you call a method handle created with a lookup.find* using
mh.invoke/mh.invokeExact
in a middle of a Java code there is no problem.
But I think there is a corner case that is currently not optimized as it
should.
With invokedynamic, you can end up with several target method handles
and if one of these
targets is constructed with a findVirtual and the receiver is not bound
to a constant and CHA finds several subtypes,
you will need type profile information for this specific method handle
of this specific callsite.
This means that you need one MDO by method handle (which do a call) by
callsite associated to an invokedynamic.
As far as I know, hotspot doesn't do that.
Charlie,
for RubyFixnum, the CHA will say that RubyFixnum has no subtype
so calling RubyFixnum::op_plus is not a virtual call and thus should be
inlined.
> 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.
Yes, and I really hope that we will not discover a hole in the API that
will prevent us
to get full speed.
> tom
Rémi
More information about the mlvm-dev
mailing list