Mon 24 Mar 2008
The Java JVM has the -Xnoclassgc argument to inhibit class garbage collection. That is so 2006. If you have a long-running server JVM, this is most likely going to leak memory.
Specifically, if your process
- Uses serialization
- Uses reflection
- Can have a remote debugger or JConsole attached
- Uses any dynamically generated classes
- Uses any 3rd party jars that do any of the above
then you have a slow, psssssssssssssssssssss sound coming from your JVM.
Do you seriously think that in 2008 you know that none of the jars on your classpath use reflection or serialization?
We live in a world now where JRuby comes along and may generate holder and wrapper classes during runtime and do all sorts of stuff to the internals trying to get things to byte-compile down. Only geniuses can truly understand this stuff.
Instead of trying to save a few millis over the course of a month of server JVM run time by turning off the class GC, make it ConcurrentMarkSweep enabled instead:
java -server -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
and let’s relegate -Xnoclassgc to the scrap-heap. It probably doesn’t do what you think it does.