Performance of non-static method handles

[Remi Forax]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Vendredi 2 Février 2018 17:52:44
> Objet: Re: Performance of non-static method handles

> At some point in the future it may be possible, with the constant folding work,
> to express the declaration of a MH locally but it gets stuffed in the constant
> pool (see amber constant-folding) if what the MH is derived from is constant.
> e.g. think of a language compiler intrinsic for ldc.

yes, 

> That may be improve some use-cases but if any input is not constant we are back to the slower path.

you can put the non constant method handle into an inlining cache and magically, it becomes a constant
see https://gist.github.com/forax/1e0734f9aa976eab8a1fe982371a44a7

> 
> Paul.

Rémi

> 
>> On Feb 2, 2018, at 5:03 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Charles,
>> usually, it's because a non constant method handle is not inlined into the
>> callsite,
>> 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,
>> Rémi
>> 
>> ----- Mail original -----
>>> De: "John Rose" <john.r.rose at oracle.com>
>>> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
>>> 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 <headius at headius.com> wrote:
>>>> 
>>>> 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
>>>> invocation?
>>>> 
>>>> - Charlie
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev