Debugging applications - OSGi in Action - page 283

8.3 Tracking down memor y leaks

Memory leaks occur in OSG i applications as in any other Java application. All you
need is something like a rogue thread or static field hanging on to one end of a spa-
ghetti ball of references to stop the garbage collector from reclaiming the objects. In a
desktop Java application, you may not notice any memory leaks because you don't
leave the application running for a long time. As soon as you restart the JVM , your old
application with its ever-growing heap of objects is gone, and you get a brand-new
empty heap to fill.
Server-side OSG i applications, on the other hand, can have longer lifetimes; an
uptime of many months isn't unreasonable. One of the strengths of OSG i is that
you're able to install, update, and uninstall bundles without having to restart the JVM .
Although this is great for maximizing uptime, it means you have to be careful not to
introduce memory leaks in your bundles. You can't always rely on the process being
occasionally restarted. Furthermore, updating a bundle introduces a new class loader
to hold the updated classes. If there's anything holding on to objects or classes from
the old class loader, it won't be reclaimed, and your process will use more and more
class loaders each time the bundle is updated or reinstalled.

Introducing the PermGen heap
Class-loader leaks can be more problematic than simple object leaks because some
Java runtimes, like Sun's HotSpot JVM, place classes in a separate heap space
called the Permanent Generation, or PermGen for short. This class heap is much
smaller than the main object heap, and its capacity is controlled by a different GC
setting: -XX:MaxPermSize . If every bundle update adds hundreds of new class revi-
sions without unloading anything, you'll probably exhaust the PermGen before you run
out of object heap space.

Any leak is a cause for concern, but depending on your requirements, not all leaks
warrant investigation. You may not even notice certain leaks if they add only a
few bytes to the heap every now and then. What's the best way to find leaks in an
OSG i application?

8.3.1 Analyzing OSGi heap dumps

As with debugging, you can continue to use your existing heap analysis skills to exam-
ine OSG i applications. Sure, there are more class loaders than in a normal Java appli-
cation; but standard Java EE containers also contain multiple class loaders, and that
doesn't stop developers from finding memory leaks inside web applications.
Let's see what an OSG i application heap dump looks like. The leaky application is
under chapter08/memory-leaks in the online examples. It consists of a single bundle
that creates and accesses a ThreadLocal variable every time the bundle starts and fails
to remove it when the bundle stops. Here's the bundle activator.