----- Mail original ----- > De: "Paul Sandoz" <paul.san...@oracle.com> > À: "Da Vinci Machine Project" <mlvm-dev@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 <fo...@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.r...@oracle.com> >>> À: "Da Vinci Machine Project" <mlvm-dev@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 <head...@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@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 > > _______________________________________________ > 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
