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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev