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
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
