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

Reply via email to