Saving PermGen space with several classloaders

Question

We're writing a large GUI app in Scala with a lot of classes, and we've had to increase the PermGen space to be able to load all classes. The app itself shows a series of screen-based activities, each of which loads its own large set of classes. Only one activity is ever loaded/displayed at the any point in time. After going through a couple of activities, we had an OutOfMemoryError in the PermGen space.

I understand that the PermGen space is garbage collected just like the rest of the heap, but I'm interested to see if I can reduce the PermGen space needed by having e.g. one ClassLoader per activity so as to allow class unloading.

So:

1. I understand that classes loaded by the system ClassLoader cannot be unloaded, as they will forever be referenced by their class loader. Is that true?
2. Provided no more instances of a class loaded by my custom class loader are around, and the class loader can be garbage collected, will its classes be unloaded, freeing PermGen space?
3. Are there any caveats regarding (or common mistakes that would prevent) class unloading?

Answer 1

...if I can reduce the PermGen space needed by having e.g. one ClassLoader per activity so as to allow class unloading.

Yes, the only way Classes are eligible to be unloaded is if the Classloader used is garbage collected. This means that the references to every single class and to the classloader itself need to be zero.

How big is your PermGen? You may get away with just bumping PermGen with :

-XX:MaxPermGen=256m

on your command line. It's not uncommon to set it to 512m. If you want a truly robust solution, you will need to go the route of using a custom class loader per 'activity'. To help with debugging, add the following self explanatory argument to your command line as well:

-XX:+TraceClassLoading

This will print out classes as they are loaded in the JVM to the command line.