MethodHandle.invoke* performance

[Remi Forax]

On 04/03/2013 07:00 PM, Julien Ponge wrote:
>
> Remi,
>
>
> Did you publish Dalvik changes somewhere? (or plan to?)

The official (visible) repository is here
   https://bitbucket.org/jpilliet/android-292
but it only contains the patches to compile android with 1.7,
the rest of the patches will be available ...
when available.

>
> Cheers

cheers,
Rémi

>
>
> On Wed, Apr 3, 2013 at 6:32 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 04/03/2013 06:12 PM, Cédric Champeau wrote:
>     > Le 03/04/2013 17:50, Remi Forax a écrit :
>     >> Sorry to be rude, but it's still a micro-benchmark ...
>     > First of all, yes, it is :) And as the classical fibonacci
>     benchmark,
>     > it's useless but relevant for understanding how things work :)
>     >> for invokedynamic, it's not in theory, if your method handle is
>     constant
>     >> either because it's a static final or because it is nested in a
>     >> CallSite, it's constant for the JIT, thus fully optimized.
>     >>
>     >> for method handle on stack, the method handle is obviously not
>     constant
>     >> moreover the JIT is not able use trick to make it constant (like
>     >> hoisting it out of the loop,
>     >> or doing the inlining algorithm in a backward way etc.)
>     >> More on that later ...
>     > Well, even if I make my MH variable declaration "final", the
>     performance
>     > is the same, so I assume there's no local analysis, right?
>
>     'final' on a local variable is a modifier for the compiler, not
>     for the JIT.
>     There are several local analysis, but not the ones you think.
>
>     >> As you said it's a micro-benchmark so you end up with unusual good
>     >> performance,
>     >> by example the call to j.l.r.Method is optimized as never it
>     will be in
>     >> a real program
>     >> (you call the method in the same unit it was declared and
>     >> you have less than 3 instances of Method that are called more
>     than 60
>     >> times).
>     >>
>     >> Now, Krystal is currently working to add a cache when a method
>     handle is
>     >> called,
>     >> so in few betas, the performance of method handles of your
>     >> micro-benchmark will improve dramatically.
>     > That's good to know :)
>     >> And the cache of MethodHandle is better that the cache which is
>     used for
>     >> j.l.r.Method because it can be local to a callsite and not
>     global (in
>     >> fact local to one callsite in the code of j.l.r.Method that is
>     used by
>     >> the invocation path when you call "invoke").
>     >>
>     >> Anyway, because it's a micro-benchmark the result will be as
>     useless as
>     >> now to predict the behaviour of a real world program.
>     > I can perfectly understand why some path is optimized or not,
>     what I
>     > find surprising is more the order of magnitude here. So yes,
>     calling
>     > invoke() takes more than 50s where reflection takes only 1.2s,
>     and even
>     > invokeExact is slower (~3 to 1). My point is more than if
>     MethodHandles
>     > are branded as "faster" than reflection (I heard you say it ;)),
>     then
>     > there is something wrong.
>
>     I say that in the context of proxies, i.e. where you can emit an
>     invokedynamic to store the method handle at callsite, method
>     handle are
>     faster than using reflection because you don't need proxies anymore
>     (remember I said that too :).
>
>     > You should expect people doing stupid things like me, thinking
>     it will be faster than plain reflection. At least, the docs should
>     mention something about performance.
>
>     The javadoc is the spec, we are talking about the Oracle
>     implementation
>     of the spec.
>     On Android, Jerome and I have run some tests that shows that a
>     MethodHandle.invokeExact is always faster than a call to the
>     Reflection,
>     it's just because the reflection is super slow on Android not the
>     opposite.
>
>     >> cheers,
>     >> Rémi
>     > Thanks for your answer :)
>
>     Rémi
>
>     _______________________________________________
>     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