speed of invokeExact

Jochen Theodorou blackdrag at gmx.org
Fri May 10 01:37:45 PDT 2013


Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
> That's because your method handle is not constant and so the compiler cannot inline the call.

And you tell me that in the first case the call was inlined? That is 
unexpected. And if that is the case, then why does 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);
>>>             }
>>>             long t2 = System.nanoTime();
>>>             System.out.println((t2-t1)/tmax);
>>>         }

take that long as well? Maybe it changed, but I thought only handles 
coming from a final field are constant enough for inlining. If I compare 
to 1.7.11 (or 1.7.6) then I get around 23 for the first, and 200-300 for 
the second and third test. That is about a factor 10-15 slowdown, that 
is what I would expect from the call not being inlined for example. But 
I always thought 1.7 will not inline in this case at all. On my 1.8 it 
was almost a factor 100. So unless the noninlined call on a method 
handle got extremely expensive compared to 1.7, there must be something 
else 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



More information about the mlvm-dev mailing list