speed of invokeExact
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
Re: speed of invokeExact
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
Re: speed of invokeExact
On May 7, 2013, at 8:04 AM, 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. Do you have any numbers? The problem is that if the MH is not constant we can't do any inlining and it will be an out-of-line call (with a trampoline in between). Is your DMH a static or virtual? -- Chris 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
Re: speed of invokeExact
On 05/07/2013 07:31 PM, Christian Thalinger wrote: On May 7, 2013, at 8:04 AM, 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. Do you have any numbers? The problem is that if the MH is not constant we can't do any inlining and it will be an out-of-line call (with a trampoline in between). Is your DMH a static or virtual? -- Chris Christian, I understand why you need a trampoline for a virtual call but why do you need a trampoline for a static call ? Rémi 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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: speed of invokeExact
On May 7, 2013, at 3:44 PM, Remi Forax fo...@univ-mlv.fr wrote: I understand why you need a trampoline for a virtual call but why do you need a trampoline for a static call ? The arguments have to be reordered, since the MH is a leading argument that must be deleted (in the case of a DMH). For compiled calls, this means register shuffling. (In JDK 7 it's worse for compiled calls. Argument reordering is done in several trampolines: First convert the compiled call to interpreter argument format, then tweak the interpreter stack, then convert back to compiled argument format.) The cost of reordering arguments could be hidden by inlining the target of the DMH into the DMH trampoline (and/or making an alternative entry point to the target method). We don't do this yet. To put it another way, there's a choice in the system for sharing vs. customizing such trampolines. We share more than customize, currently. Cases like yours cause us to note the downsides of this choice. If you share argument reordering code, then you have two indirect jumps. First, to the DMH compiled code handler. Second, after the handler shuffles arguments, to the target of the DMH (which is not constant from the POV of the compiled code handler). — John P.S. The private linkToVirtual, linkTo* intrinsics were introduced in the JDK 8 implementation to decouple the argument shuffling from the actual jump to the target method, so that the former could be managed separately. The shuffling code is generated by makePreparedLambdaForm. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
