Attila Szegedi wrote:
>
> 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.
In really large applications, this footprint can become a real pain
though. Should an application that compiles 10k methods need 10k
classloaders taking up heap space?
Also, it's just plain gross...I should be able to specify that "this
class is transient, and I don't care if it gets GCed when all instances
of it go away" rather than having to hack around this.
Plus then there's the fact that this "sticky" behavior is on-purpose and
not overridable, because of this line from ClassLoader.java:
// The classes loaded by this class loader. The only purpose of
this table
// is to keep the classes from being GC'ed until the loader is GC'ed.
private Vector classes = new Vector();
Talk about irritating. So now not only do I have to have a classloader
per "method class", I have to pay the cost of an additional Vector. Suck.
I've honestly considered hacking around this in JRuby because it's
really irritating and increases the memory load substantially.
> 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.
JRuby absolutely needs a lighter-weight construct like John Rose's
autonomous methods, because at the end of the day we're only interested
in getting the bytecode callable. JRuby (and other language impls) have
to hack around the fact that each compiled method has to live in a class
with its own metadata (in permgen), symbol tables (in permgen), and
symbolic name (parts in permgen and parts in classloader, for bits of
code we don't really need unique names for). If I could pick one feature
I'd like to have for JRuby, this would be it.
To further solidify my point...JRuby 1.1RC2 will include a new config
property to limit the total number of JITed methods at any time, so it
doesn't try to JIT everything and use up more permgen than it should.
Granted, there should be a limit either way, or an LRU cache of some
kind. But having to do it because every method takes up too much permgen
is pretty disgusting.
- 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
-~----------~----~----~----~------~----~------~--~---
