cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Class unloading
Date Wed, 07 Jan 2004 22:14:40 GMT
Rob Adams wrote:

>According to Sun, in Java 1.2 and above classes can only be unloaded if
>the ClassLoader used to load them is not reachable, i.e. the classloader
>used to load them is garbage collected.  Classes loaded with the System
>ClassLoader can never be garbage collected.
>
>We have a cocoon site with a very large number of xsps (like 1400 of
>them) and the memory required to hold all these classes is memory is too
>much.  We would need, therefore, some sort of MRU-based class unloader
>scheme whereby classes less recently used would have their classloaders
>freed so that the classes themselves could be garbage collected.  This
>would require a thin wrapper around the System classloader implementing
>the ClassLoader interface, as well as some sort of a meta-classloader
>infrastructure through which classes would actually be loaded, and which
>would monitor the JVM memory resources and remove references to
>classloaders, as well as a way of maintaining an MRU list of resources.
>
>Cocoon must already implement much of this infrastructure since most of
>that would already be required simply to reload classes.  I would
>expect, therefore, that all that would really be required would be the
>MRU list and the system monitoring to implement this.
>
>My question to the cocoon devs is then: it is possible already in cocoon
>to use such an unloading scheme, and if not where in the code would be
>the best place to start to implement it.
>  
>

Cocoon already uses a custom classloader to load XSPs. This classloader 
is unique for all XSPs, but is recreated each time an XSP is recompiled. 
So in a running system where XSPs never change, you end up with all 
corresponding classes to be loaded in a single classloader.

A solution to your problem could be to have a classloader for each XSP, 
and store this duet in the transient store, which has a MRU policy. 
However, the size of a classloader should be taken into consideration as 
if it's big, the remedy maybe worse than the cure.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message