Attila Szegedi wrote: > 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 think the counterpoint to that requirement would be "I don't care". I'm using <clinit> in my compiled classes to initialize things like Ruby string objects, Ruby stack trace positioning information and so on. I really would be happy as a clam if <clinit> ran again...and of course the assertion that <clinit> is only going to run once is impossible to guarantee anyway, since people in our case end up loading the same classes in separate classloaders anyway. Perhaps people are doing things with side effects in <clinit>...that's their problem, not mine. It seems quite unfortunate to have an artificial limitation on class GC to support a few bad designs. It's time to Free the Class! > (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.) A class would be fine, with two caveats: - GC-able without 1:1 classloaders - easy to generate really light classes that, for example, will only ever contain one method and (maybe) no <clinit>. If classes can be GC-able and super lightweight...I have no concerns. And both seem to be implementation details we ought to be able to solve. > 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. Yes, I'm considering various chunking mechanisms. The tricky bit for me is that when a Ruby script starts executing, none of its Ruby classes exist, none of the methods defined therein are bound. And it's binding classes at runtime that end up chewing up class+classloader, one per method in the system, so I can have a "Callable" object that goes straight into the precompiled method without reflection. And of course there's methods defined in 'eval', which will not be compiled immediately but may JIT later. So there may be a way to get chunking working, but as you say it's very artificial and potentially very complicated to do in the extremely late-bound Ruby. - 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 -~----------~----~----~----~------~----~------~--~---
