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 <fo...@univ-mlv.fr > <mailto:fo...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
