Which version of the jvm are you seeing this problem on, and are you adapting the method handle every time as well as exact invoking it?
We avoided invoke and invokeExact calls from Java (because they were sometimes painful to get correct in the case of varargs methods) by having the fallbacks return the adapted method handle to an exact invoker, like this MethodHandle invoker = MethodHandles.exactInvoker(type()); setTarget(MethodHandles.foldArguments(invoker, fallback)); As far as I remember we didn't have any serious speed issues with invoke or invokeExact in Java (7.0u2 - we'd already moved to the above approach by the time u4 came out), but did have issues with the speed of generating the adapter method handles, so it's good to cache them in a central cache or against your function objects if they are likely to be used again. On 07/05/2013 16:04, "Jochen Theodorou" <blackd...@gmx.org> wrote: >Hi, > >I am currently investigating here some performance issues and I may have >found a culprint here - invokeExact. My case is one where method caching >fails and I will have to do an invokeExact from Java - meaning without >the invokedynamic bytecode and with a non constant method handle. I am >aware of that being a non optimized path in indy, but it does not really >look fast to me at all. Maybe compared to Reflection, but to a runtime >generated class for the method invocation, it seems to be very very >slow- at least on my "64-Bit Server VM (build 25.0-b14, mixed mode)" here. > >Now.. is that commonly known? Did I see wrong? Is there a way to improve >the speed (it is a DirectMethodHandle I am invoking already)? > >bye Jochen >_______________________________________________ >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
