On May 11, 2011, at 7:25 AM, Charles Oliver Nutter wrote: > How would I go about debugging a > failure in the chain that happens some time after I've wired it up and > bound it to a call site?
Everything after the "method__0$RUBY$fib_ruby" frame (invoke_L5) is always going to be opaque. If your call site were statically linked, the callee would be named in the bytecodes of "method__0$RUBY$fib_ruby". As it is, the method handle is some value bound into a call site or computed dynamically. Since method handles chain via tail-calls, there's little or no evidence about how you got from "fib_ruby" to the CCE. The JVM could save a breadcrumb trail, but it would cost something to store the info. Expect the invoke_L5 stuff to go away soon, replaced by ricochet frames. Suggestion: Store the initial MH yourself just before invoking it. In debug mode only, of course. In the case of invokedynamic, we probably need some way to display the CallSite associated with an indy instruction. If "fib_ruby" is using indy to get to the CCE, the missing information is hard to get. Maybe a backtrace should somehow display the CallSite bound to an outgoing call. Not sure what that would look like. I suppose you could also bind the CallSite to something that would save clues for debugging. Once you have the MH invoked by the call site, you can make better guesses. But if it is an MH graph with the CCE buried inside, you need an MH inspector. We haven't defined MH reflection yet. (It's like Java 1.0 in that respect; reflection will have to come in the JSR 292 MR.) Still, you can make educated guesses about an MH by looking at its low-level structure as a Java object. -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
