That permanent generation had better provide some pretty damn amazing optimizations or I'm going to add it's inventor to my list of people to track down and torture at next JavaOne. It turns out you can only reload a Tomcat webapp so many times before the PermGen space fills up and everything dies. That's annoying enough in development but it means I can't upload a new WAR file to our test server regularly without also bouncing Tomcat. Right now our continuous integration server (Bob the Builder) is doing just that after every commit so the server isn't staying up all that long.
Mock objects for unit tests will also run afoul of PermGen space and apparently something in Eclipse does too because every so often it dies on me too. Sigh.
Category: Code and Geek Stuff, Java
Nuno Sousa says:
Hi.
If you are using Sun’s JVM, Garbage Collection for the Permanent Generation is switched off by default. Since you are using Tomcat and redeploying WAR files, tomcat also creates new class loaders, so it is a good thing to enable Class Unloading in the VM also — this to is switched off by default.
In summary: add these options to the java command
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
Have fun,
Nuno
Odi says:
Use JConsole to analyze if you have sized the memory pools according to your app needs. No need for a big heap if all you lack is PermGen. You may want to tune PermGen and CodeCache (that’s for classes compiled by HotSpot): -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=64m
However, crashes due to PermGen OOM indicates a memory leak with class loading. Especially when redeploying WARs, the chances for class leaks are very big. If anything still has a reference to an object of your webapp, that effectively prevents unloading of its classloader and so all classes in the WAR. Common leaks are DB driver registrations with the JDBC driver manager, Swing listeners, SoftReferences, Objects in JNDI, RMI, unterminated threads, Logger instances, JMX beans, open sockets, open files. Use a heap analyzer (jmap / jhat) to find the dangling references.
But the PermGen inventors are not to blame. It’s YOU not cleaning up properly.
Joe says:
Specifically with JDBC (since it’s often the most common problem) – move any JDBC drivers in your webapps lib into Tomcat’s common/lib folder instead.
This solved nearly all my (web) PermGen problems in one go …
Odi says:
Nuno, these options are only effective if you have enabled the *concurrent* mark and sweep GC (CMS) with -XX:+UseConcMarkSweepGC.