On 2008.01.14., at 14:26, Matthias Ernst wrote:
> > On Jan 14, 2008 2:06 PM, Kresten Krab Thorup <[EMAIL PROTECTED]> wrote: >> >> I think that the best way to improve this would be to add a new kind >> of class loader that would permit unloading classes loaded by it. >> That would relieve us from creating a new class loader for every >> class >> that needs to be independently unloaded (such as compiled methods). > > Is the overhead substantial for individual class loaders apart from > the Java heap? Do they > live in the permgen? Do they complicate the verification algorithm? > Has anyone investigated that? No, they don't really complicate anything as far as I know. They don't live in permgen. They're just ordinary Java objects usually referenced from Class objects and Thread objects, and can be GCed (except for system class loader). They do have a bit of a memory footprint -- in addition to their own fields, each does create one 16-element hashset, one 16-element hashmap, one 11-element hashmap, and one 10-element vector. Rhino uses the classloader-per-function scheme since forever and it's never been a big deal. I do agree that it'd be nice if there existed an atomically loadable/unloadable unit of code in JVM that's lighter than the currently only possible "Method-in-a-Class-in-a-ClassLoader", even just because it'd make this rather baroque construct no longer necessary, but even the current situation itself is, well, tolerable. Attila. -- home: http://www.szegedi.org weblog: http://constc.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
