On 10/1/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > Ok...I'm firing a few shots across the bow of the Java machine here, and > I'd love to hear all input. But I wanted to do a retrospective of a > number of things I've learned during the implementation of the JRuby > compiler. > > #1. We need lightweight method objects > > In JRuby, where methods can be defined and discarded on a whim, we have > to be able to generate lightweight objects on demand that can be garbage > collected as easily as any other object. In our case, this means that > the JRuby JIT must generate single-method classes at runtime in their > own GCable classloaders. So if we JIT a thousand methods, that's a > thousand tiny classes in a thousand (not-so-tiny) classloaders. It works > great in practice, except for two details: > > - classloaders are not cheap to spin up (I'd even say "expensive") > - classloaders take up too much memory > > The situation is aggravated by our desire to do more and more code > generation: > > - generating direct-invoking stubs to bind methods into named slots on > the MOP > - generating call adapters that make use of inline caching information > to optimize multiple fast paths > - generating switch-based "fast dispatchers" on demand that can omit > dynamic method lookup entirely > - generating type and arity-specific call interfaces throughout the call > chain to allow more specificity in dispatch > > > The more we choose to generate, the more the expensive cost of a > classloader-per-generated-class becomes painful. What we really must > have sooner rather than later is a way to define lightweight, GCable > autonomous methods that we can loosely bind together and not have to > bend over backwards to manage and dereference. We need GCable classes, > and better yet we need super-lightweight classes to represent autonomous > methods. NEED.
I'm looking at a way of minimising the classes generated for closures and I'm thinking of compiling the closure body as a synthetic static method in the enclosing class. The Closure object would then be an instance of a generic closure class which dispatches to the static method via reflection. It occurs to me that this could be generalised to allow the generation of lightweight method objects. If we had a way of dynamically adding static methods to some utility class returning an instance of java.reflect.method then these cold be used as lightweigth method objects. Imagine a class java.util.DynaHome with a single method Method makeMethod(byte[]). Calling that method with some bytecode would add the static method to java.util.DynaHome. It would have an arbitrary unique name and an instance of method would be returned which allows the method to be called. When the instance of metod is GCd the method is removed from java.util.DynaHome. I have absolutly no idea how feasible this is but I think it, or soemthing like it would be pretty useful. John Wilson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
