John Rose wrote: > Dear language designers and implementors: > > I have blogged a dynamic invocation rationale piece: > http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for > > It is a prequel to the forthcoming JSR 292 Early Draft Review > (which will be public). > > This should make the EDR easier to read and understand. > By itself it doesn't promise anything, but it motivates the > decisions the Expert Group is moving towards. > > Your comments are always welcome.
Support for real method handles seems like an excellent way to support dynamic invocation, and it eliminates at least one place where we (JRuby) currently generate a lot of classes: as fast method invokers. So in that regard it eliminates one case where we'd hope to have autonomous methods in JRuby and helps reduce our class load (but does not eliminate all such cases...more later). I'm not clear on one thing, though: [quote] As noted above, the target method may be an adapter, a direct reference to a real bytecoded method, or something complex like a closure over a tree-walking interpreter. [/quote] In our case, for most methods the "target method" will be an adapter with a direct reference to a real bytecoded method. For performance reasons, all method invocations in JRuby currently pass through a bytecode-generated adapter that then directly invokes the target method. This not only eliminates reflection overhead, but allows us to make more of the call path monomorphic and therefore inlinable. So the question then is this: if the JVM is going to provide method handles for us, and we ultimately want a method handle to a "real bytecoded method", how can we still decorate the invocation with language-specific adapter logic? Or put another way: I don't want a method handle to the target method if that disallows my attaching adapter logic; but that may not matter if I can provide as part of the method handle generation *just* the pre/post call logic and have the JVM wrap the invocation for me. The case in JRuby is that the adapter not only does the direct invocation of a target method, but constructs/releases frame objects, watches for certain types of non-local flow control (in-closure breaks, continues, etc), and in some cases coerces Java exception types into Ruby-friendly exception types. This largely applies to Ruby methods that require such coercion, but I could see doing similar operations when calling Java methods, to better enlist them in the JRuby runtime logic. So then autonomous methods. Obviously if I have to generate my own adapters, autonomous methods will be very useful (or at the very least, the runtime characteristics of autonomous methods will be useful, e.g. garbage collection of classes rather than classloaders, lightweight "method objects", and so on). The area where autonomous methods will always be needed--even if method handles are decoratable in the way I describe above) is for dynamically composing a collection of bytecode-based methods into a metaclass. So I am also interested in hearing how the method handle/dynamic linking logic described in your post will tie together with autonomous methods and generally "artificial" classes (really, "method bags") such as those found in JRuby and Groovy. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
