speed of invokeExact
Christian Thalinger
christian.thalinger at oracle.com
Thu May 9 17:40:57 PDT 2013
On May 9, 2013, at 2:26 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
> Am 08.05.2013 23:12, schrieb John Rose:
>> On May 8, 2013, at 5:33 AM, Jochen Theodorou <blackdrag at GMX.ORG> wrote:
>>
>>> Am 07.05.2013 19:31, schrieb Christian Thalinger:
>>> [...]
>>>> 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?
>>>
>>> arg... looks like I made a mistake. It is not the invokeExact that is
>>> slow, it is my preparation of the handle that is slow.
>>
>> So it's an insertArgs and asType that's slow. Can you distill the operations into a micro-benchmark for us?
>
> to reduce it to only asType:
>
> compare the times of this:
>
>> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, "toString", MethodType.methodType(String.class));
>> int tmax = 1_000_000;
>> for (int k=0; k<20; k++) {
>> long t1 = System.nanoTime();
>> for (int i=0; i<tmax; i++) {
>> String s = (String) mh.invokeExact(str);
>> }
>> long t2 = System.nanoTime();
>> System.out.println((t2-t1)/tmax);
>> }
>
> with this:
>
>> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, "toString", MethodType.methodType(String.class));
>> MethodType invokeType = MethodType.methodType(Object.class, String.class);
>> int tmax = 1_000_000;
>> for (int k=0; k<20; k++) {
>> long t1 = System.nanoTime();
>> for (int i=0; i<tmax; i++) {
>> MethodHandle invoker = mh.asType(invokeType);
>> Object o = invoker.invokeExact(str);
>> }
>> long t2 = System.nanoTime();
>> System.out.println((t2-t1)/tmax);
>> }
>
> The first one has times of about 9-15 on my machine, the later one
> 800-900. I am aware that this is a test in which hotspot should throw
> out the invocation completely, but it does not.
That's because your method handle is not constant and so the compiler cannot inline the call.
-- Chris
> Even more interesing is
> when you reduce the test even further:
>
>> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, "toString", MethodType.methodType(String.class));
>> MethodType invokeType = MethodType.methodType(Object.class, String.class);
>> int tmax = 1_000_000;
>> for (int k=0; k<20; k++) {
>> long t1 = System.nanoTime();
>> for (int i=0; i<tmax; i++) {
>> MethodHandle invoker = mh.asType(invokeType);
>> }
>> long t2 = System.nanoTime();
>> System.out.println((t2-t1)/tmax);
>> }
>
> Now this should really be optimized away completely by hotspot, but is
> not and takes about the same time as the second case... which is not
> surprising since the asType call is totally dominating the "benchmark".
>
> btw, the test was with a jdk 1.8.0 ea with tiered compilation turned
> off. The tests contain no warmup, but that's what why the test is
> repeated 20 times to see the development of the values instead of doing
> a one time measurement. And the values in this test go up and down a lot too
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the mlvm-dev
mailing list