On Jun 7, 2011, at 3:38 PM, Charles Oliver Nutter wrote: > So I figured I'd check assembly output, and I was surprised to see a > callq right where I expect to see the literal. Are > MethodHandle.constant handles not inlined right now?
Here is what constant(Object.class, foo) reduces to: #wellKnownIdentityFn.bindTo(foo) This should inline very nicely. What is the type you pass to MHs.constant? If it's not Object, call it T. In the case of a type other than Object, we have: rawRetype(#wellKnownIdentityFn, methodType(T, T)).bindTo(foo) where rawRetype is an internal trusted constructor which asserts that the result is trusted to be T, not just Object. This should inline also. There's a potential problem here: The methodHandleWalk module will emit a return of an Object value (from wellKnownIdentityFn, not its real name) from an adapter that returns a value of type T. This bytecode would be rejected by the verifier, but I don't think the verifier runs on MH graphs. Maybe the methodHandleWalk modules is tripping over some aspect of this MH graph or the resulting bytecode. -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
