usually, it's because a non constant method handle is not inlined into the
so it's as fast as a function call or a method call when you ask to not inline.
A way to improve the perf is to profile the method handles that can be seen
when doing an invokeExact,
and inline them if they are few of them, making invokeExact acts as a n-morphic
inlining cache (with an identity check instanceof a class check).
Obviously, it's also easy to emulate think kind of cache with an invokedynamic,
i think Golo has such cache (Golo lambdas are plain method handle),
and if you want to go fully circular, you can simulate invokedynamic with an
invokeExact on a constant method handle :)
see you tomorrow,
----- Mail original -----
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Da Vinci Machine Project" <firstname.lastname@example.org>
> Envoyé: Vendredi 2 Février 2018 13:33:49
> Objet: Re: Performance of non-static method handles
> Vladimir Ivanov did some work a few years ago on MH customization for hot MH
> instances. It’s in the system. That should get better results than what you
> show. I wonder why it isn’t kicking in. You are using invokeExact right?
>> On Feb 2, 2018, at 1:26 PM, Charles Oliver Nutter <head...@headius.com>
>> Hey folks!
>> I'm running some simple benchmarks for my FOSDEM handles talk and wanted to
>> reopen discussion about the performance of non-static-final method handles.
>> In my test, I just try to call a method that adds given argument to a static
>> long. The numbers for reflection and static final handle are what I'd expect,
>> with the latter basically being equivalent to a direct call:
>> Direct: 0.05ns/call
>> Reflected: 3ns/call
>> static final Handle: 0.05ns/call
>> If the handle is coming from an instance field or local variable, however,
>> performance is only slightly faster than reflection. I assume the only real
>> improvement in this case is that it doesn't box the long value I pass in.
>> local var Handle: 2.7ns/call
>> What can we do to improve the performance of non-static method handle
>> - Charlie
>> mlvm-dev mailing list
> mlvm-dev mailing list
mlvm-dev mailing list