I cannot for the life of me find a definition of what the Java VM flag CMSClassUnloadingEnabled actually does, other than some very fuzzy high-level definitions such as "gets rid of your PermGen problems" (which it doesn't, btw).
I have looked on Sun's/Oracle's site, and even the options list doesn't actually say what it does.
Based upon the name of the flag, I'm guessing that the CMS Garbage Collector doesn't by default unload classes, and this flag turns it on - but I can't be sure.
Update This answer is relevant for Java 5-7, Java 8 has this fixed: https://blogs.oracle.com/poonam/about-g1-garbage-collector,-permanent-generation-and-metaspace Kudos go to mt.uulu
For Java 5-7:
The standard Oracle/Sun VM look on the world is: Classes are forever. So once loaded, they stay in memory even if no one cares anymore. This usually is no problem since you don't have that many purely "setup" classes (= used once for setup and then never again). So even if they take up 1MB, who cares.
But lately, we have languages like Groovy, that define classes at runtime. Every time you run a script, one (or more) new classes are created and they stay in PermGen forever. If you're running a server, that means you have a memory leak.
If you enable CMSClassUnloadingEnabled the GC will sweep PermGen, too, and remove classes which are no longer used.
[EDIT] You will also have to enable UseConcMarkSweepGC (thanks to Sam Hasler). See this answer: https://stackoverflow.com/a/3720052/2541
According to the blog post The most complete list of -XX options for Java JVM, it determines if class unloading is enabled under the CMS garbage collector. The default is false. There is another option called ClassUnloading that is true by default which (presumably) affects the other garbage collectors.
The idea is that if the GC detects that a previously loaded class is no longer used anywhere in the JVM, it can reclaim the memory used to hold the classes bytecode and/or native code.
Setting CMSClassUnloadingEnabled might help with your permgen problem if you are currently using the CMS collector. But the chances are that you are not using the CMS, or that you have a genuine classloader related memory leak. In the latter case, your class will never appear to the GC to be unused ... and will therefore never be unloaded.
Aaron Digulla says "classes are for ever". This is not strictly true, even in the purely Java world. In fact, the lifetime of a class is tied to its classloader. So if you can arrange that a classloader is garbage collected (and that is not always an easy thing to do) the classes that it loaded will also be garbage collected.
In fact, this is what happens when you do a hot redeploy of a webapp. (Or at least, that's what should happen, if you can avoid the problems that lead to a permgen storage leak.)
An example where this is useful:
Setting -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled on our Weblogic 10.3 JVM helped resolving a problem where the JAX-WS implementation created a new proxy class for every web service call, eventually leading to out of memory errors.
It wasn't trivial to trace. The following code always returned the same proxy class for port
final MyPortType port =
Service.create(
getClass().getResource("/path/to.wsdl"),
new QName("http://www.example.com", "MyService"))
.getPort(
new QName("http://www.example.com", "MyPortType"),
MyPortType.class);
Internally, this proxy delegated to an instance of weblogic.wsee.jaxws.spi.ClientInstance, which again delegated to a new $Proxy[nnnn] class where n was incremented at every call. When adding the flags, n was still incremented, but at least those temporary classes were removed from memory.
On a more general note, this can be very useful when making heavy use of Java reflection and proxies through java.lang.reflect.Proxy
