- Mail original -
> De: "Paul Sandoz"
> À: "Da Vinci Machine Project"
> 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
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. That
s/instanceof/instead of :)
Rémi
- Mail original -
> De: "Remi Forax"
> À: "Da Vinci Machine Project"
> Envoyé: Vendredi 2 Février 2018 14:03:35
> Objet: Re: Performance of non-static method handles
> Hi Charles,
> usually, it's because a
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
MH customization doesn't help here. The benchmark measures the cost of
MH type check + MH.invokeBasic() call.
For MH.invokeExact(), type check is ptr comparison of MH.type against
MethodType associated with the call site.
MH.invokeBasic() involves the following steps:
MethodHandle
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
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