On May 18, 2009, at 5:33 AM, Charles Oliver Nutter wrote: > Ok! I have managed to dispatch single-arg method calls using the new > invokedynamic!
That's a good night's work! I'm sorry--well, not--that I slept through it. > The logic is fairly primitive right now: http://gist.github.com/113440 I like that file; it reads well. The first two lines of GuardedRubyMethodHandle.invoke are your fast path; that's where we need to get the maximum amount of inlining. The JVM interpreter gets to those lines very quickly (without intervening bytecodes) when it executes an invokedynamic instruction. Christian Thalinger and I are working on making this true also in the compiled code. The call to entry.typeOk looks like it might be megamorphic; if so that's a potential performance problem. There might be a way to refactor this with method handles to avoid the megamorphism; that's what guardWithTest is supposed to do. We'll get a better idea of what to work on when we look at the disassemblies of compiled code, but we'll need another round of compiler support to get this far. The expression entry.method.call might also have a megamorphism (your nemesis, of course). I think it wants to be entry.mh.invoke, or even ((MethodHandle)entry).invoke, where entry is a JMH. Minor nits: I suggest making bootstrap in registerBootstrap be a private static final like DEFAULT. And you might consider naming those statics after their methods (modulo Java naming conventions): BOOTSTRAP, INVOKE. > Rather than try to introduce method handles throughout the system, > this > current design simply replaces my existing CallSite logic with > invokedynamic. The dynamic call from Ruby code passes threadcontext, > caller object, target object, and arguments through invokedynamic, > which > is then bootstrapped with a new dyn.CallSite instance and my > GuardedMethodHandle. GMH simply asks the cached CacheEntry tuple if > it's > still valid for the incoming type, and then either dispatches > through to > the JRuby DynamicMethod object or re-looks-up the method and > reinstalls > in the dyn.CallSite. > > So far it appears to be at least no slower doing it this way, but I'm > hoping we'll be able to coax more performance out of this. That's because you haven't run into the deoptimization the compiler does on invokedynamic. > It's also pretty crashy right now; several tests I tried simply blew > up. > I can provide dumps and reproduction cases on demand. There are a number of crashes I know about. (Remi has been good at producing them!) Please do some triage, and pick me a crash to work on that seems most in your way (sans workaround). Reduced (one-file) test cases are most welcome. > Comments welcome...time to get some sleep. Thanks a million! -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
