constantPoolClass in Java heap?

Question

I have inherited a Java applet (an actual <APPLET>) which throws an OutOfMemory exception after about 4 days of runtime. The nature of the applet is such that people really will leave it open for long periods of time.

After almost two days running, jmap -histo shows the top heap consumers as:

    num  #instances   #bytes  class name
    ---  ----------   ------  ----------
      1:      14277  7321880  <constantPoolKlass>
      2:      59626  5699968  <constMethodKlass>
      3:      14047  5479424  <constantPoolCacheKlass>
      4:      14277  5229744  <instanceKlassKlass>
      5:      59626  4778944  <methodKlass>
      6:      71026  3147624  <symbolKlass>

The trouble is, I don't understand what any of these things are. There are at least two things going on: constantPoolKlass+constantPoolCacheKlass+instanceKlassKlass appear related, as do constMethodKlass+methodKlass. From the names, they appear related to a class loader.

If I had to guess I'd say the applet has creating about 14,277 objects where each object has about 4 methods, for about 59626 methods total. Yet the jmap output doesn't show any class with such a large number of instances, nor does it look like the sum total of other class objects add up to 14277. So maybe I'm incorrect about what these objects do. Can someone explain?

Answer 1

Yup, looks like you are leaking class loaders. If you're not actually creating class loaders in you own code (typically through URLClassLoader.newInstance or XSLT) then it may be related to reloading the applet (although you would usually get back the same class loader). Possible causes of leaks are ThreadLocal, JDBC drivers and java.beans.

Answer 2

Spot on - obviously a ClassLoader issue. Very strange to see that in an applet though; normally it's only a problem with appservers or IDEs.

2 ways to debug this: either get a real heap profiler that can show you where your runaway class data is referenced, or patch the API classes as described here: http://www.onjava.com/pub/a/onjava/2004/06/30/classloader2.html?page=2