On Oct 24, 2008, at 3:13 AM, Rémi Forax wrote: > During the JVM Summit, you say that BGGA closure is the major use case > for allowing to call a MethodHandle directly using its method > "invoke".
Yes, it's a major use case in case BGGA is adopted. (Which I think should happen, but that's a different conversation.) But it is not *the* major use case. A far more direct and central use case is the task of wiring up adapters and decision trees, using higher-order functions (combinators). The combinators given in the JSR 292 EDR are a core set, but they are not intended to be the whole toolkit. (We can't predict what the whole toolkit will be.) In general, you use MHs.insertArgument to build bound method handles to perform language-specific adaptation and dispatch. The attached code (using the bound-in data to fill in free variables) needs to perform the language-specific tests and conversions. Perhaps it also attaches language specific control blocks, as implicit arguments. Eventually the target method gets called, after all the tests and argument adjustments. That invocation point is a direct MH.invoke call. Basically, if you want to build combinators, you need (a) bound method handles and (b) direct MH.invoke calls. Step (a) creates the wrapper that gets called, and step (b) calls the next guy in line. This is a sort of tinkertoy set that can be used to build any needed structure. BMH creation is one kind of connection point, and MH.invoke is the complementary end. > I don't think it's a good example since BGGA closures are > covariant/contravariant, > so the MethodHandle behind a closure can't be called directly > because it > need to be adapted. The adaptation is (in the EDR) a hardwired case, because (it is likely) the JVM can optimize it easily. The adaptation could also be expressed as a user-written BMH. Anything more complicated than a Java implicit conversion *will* be expressed with a user-written BMH. > So I don't see a 'real' use case for calling a MethodHandle directly. > > For the backport, emulate this call is a performance problem because > unlike invokedynamic that requires to use > Linkage.registerBootstrapMethod() > on classes that contains at least one invokedynamic call site > there is no such requirement for MethodHandle.invoke() > a MethodHandle.invoke can be done anywhere > so I have to inspect all loaded classes. Check the constant pool for Methodrefs of java.dyn.MethodHandle.invoke. If they don't appear, then don't scane the rest of the class. Thanks, Remi. -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
