Java: Tracing classloader leaks

Frank Kieviet has written a very interesting article on how to use existing free tools to easily track down hanging references to code that has been unloaded from a JVM.

Anyone writing Java code that has to deal with code loading and unloading is probably familiar with problems related to releasing those last dangling references to the code being unloaded - without unloading the code, the classloader won't go away, the memory won't all be released, and the behavior of the JVM when the same code is loaded again cannot be guaranteed...

Somewhere where this particularly bites hard is with JNI code... due to the design of the JNI API, there's a constraint that it's forbidden to load the same JNI library into two different classloaders at the same time... so if you cannot release that last reference to your old classloader, you cannot reload the same code into the JVM without a restart.

There are of course tricks you can play to work around this - for example, you can rename the shared library file so that the JVM doesn't see it as being the same one (I believe that's what the MLet code in JMX does), but that adds complexity and is rather fragile.

The best thing to do is to track down those reference leaks in your code. Sometimes they can be pretty nasty, other times they're trivial to fix. They're just hard to find. Until now.

Thanks Frank!

( Oct 31 2006, 11:44:33 AM CET ) Permalink