On Jul 9, 2011, at 7:13 AM, Alexander Turner wrote: > I am Alex Turner - I was working on a COBOL to JVM compiler and am now > helping with a Magik to JVM compiler. I thought I might just confirm > that invokeExact has proven a lt ot quicker than invoke in our tests. > We have also noticed that using a method adapter to convert argument > counts makes things a little slower (a few percent). But using an > adapter then invokeExact is much faster than using invoke.
Yes. I expect disparity will reduce over time, but the initial implementation of inexact invoke (in Hotspot, maybe not J9) is very basic. Method handle creation is currently slow, because it calls native methods to set up the magic nodes. This needs to be refactored to be native-free (or at least intrinsified) so that inline MH creation can be optimized using normal means. For now, expect MH creation to go much slower than MH invocation. And, since inexact invoke can create temporary MHs to make up type mismatches, this means inexact invoke can also be slow. One thing that we've tried to make fast out of the box is invokedynamic's call to a MH. This performs inlining of the MH graph. Another use case which benefits from this particular optimization trick is "static final" method handles. I.e., if you want to get invokedynamic-like performance in plain Java code, consider doing your work by invoking MH constants. This means your bootstrap logic has to run in the static initializer of the class containing the constants, which is less flexible (more eager). But it's an option. > My approach from here is to try very hard to avoid invoke and only use > it when there is no realistic chance of resolving an invokeExact for > more than one call. Onward! -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
