Yeah, Rhino suffers from this too - every function gets compiled to a separate Java class implementing org.mozilla.javascript.Function, and if you want its instances to be separately garbage collectible (which you want, since they're just ordinary objects in our languages), you need to load each one of them through its own class loader, since class lifecycle is tied to its class loader.
The whole business of classes not being collectibe until their loader gets collected has to do with guaranteeing single execution of the class' static initializers. If we could get Sun to change the JVM spec so it'd allow "loose class loaders" that allow their loaded classes to get GCed, but can only load classes that don't have <clinit>() I think that'd help. (I'm still thinking in terms of classes, as I don't think we could get Sun to accept anything smaller than a class as the smallest unit of executable content that can be loaded into JVM.) Alternatively, you can go for all sorts of (admittedly artificial) lumping. I.e. you could use a single class loader per compilation unit when you know that you're compiling multiple functions from a same source (i.e. single .rb file). You get less class loaders, but as a tradeoff all function classes generated from the compilation unit become collectible only as a group. Precompilation is another alternative -- Rhino has a command-line compiler (jsc) that produces .class files. If you bundle them in a JAR, they'll obviously all get loaded through whichever class loader reads the JAR file. Attila. On Mon, 01 Oct 2007 23:52:43 +0200, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > #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. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
