I spent some time looking at the cocoon code and to do this write I'm now convinced would require a substantial rewrite, including not using the avalon framework.
I did, however, find a solution here: http://java.sun.com/docs/hotspot/gc1.4.2/ and here: http://java.sun.com/docs/hotspot/gc1.4.2/faq.html with the -XX:MaxPermSize= command line option that is now available in recent Sun JVMs. This option controls the size of the "permanant generation" for the garbage collector, which is essentially a separately managed heap for JVM internals and class files. By setting this to something big, I was able to get cocoon to run without crashing. We have 2GB of memory in our servers, so I set it to 512MB, which is enough to hold all the classes of all our XSPs. You may want to add this information to a cocoon FAQ somewhere. Thanks a lot for your help. -Rob On Wed, 2004-01-07 at 14:14, Sylvain Wallez wrote: > 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
