On 07/10/2011 10:14 AM, Alexander Turner wrote: > John, > > Thanks for your fascinating reply. I would just like to clarify something: > > " > 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. > " > > Is what you are saying here that making a method handle final static > will bring invoke performance closer to invokeExact because the > matching logic only happens once. IE the handle cannot be repatched? I > am not sure I fully understand this because (as I understand it) > making a field final does not do change the way fields in the > reference graph below the field behave. Does a mh 'know' is it final > and so not attempt to mutate itself or anything to which it refers?
Currently the JIT tries to replace method handle calls by a direct call (or chain of calls) to after inline them. This occurs if the method handle is the target of a CallSite of an invokedynamic, if the method handle is stored in a final static field or if the method handle is a constant method handle loaded by a LDC. Basically, it works if the method handle is reachable from a static root. Now, if the method handle is reachable from a static root, them JIT knows its type (its method type) so because mh.invoke(args) <=> mh.asType(methodType(args)).invokeExact(args) the JIT can fully inline mh.invoke(args). > On another note - it is great to keep hearing that so much work on > performance is in the pipeline! > > Best wishes - AJ cheers, Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
