3

I see the following from "jmap -permstat":

0x000000077736cce0      12      173472  0x00000007723425d0      dead    com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x00000007c83bea70
0x0000000777168a20      12      172264  0x00000007723425d0      dead    com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x00000007c83bea70
0x0000000780b3c810      12      172264  0x00000007723425d0      dead    com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x00000007c83bea70
0x0000000776ca6170      12      172264  0x00000007723425d0      dead    com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x00000007c83bea70
0x00000007772b28a8      12      172264  0x00000007723425d0      dead    com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x00000007c83bea70
....

There are over 6000 of these dead TransletClassLoader class loaders in permGen now, and number keeps growing until I get this error:

java.lang.OutOfMemoryError: PermGen space

I have the following JVM flag set:

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled

java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)

Why are these dead class loaders not getting cleaned up with the CMSClassUnloadingEnabled flag on? How do I fix this problem?

fruitJuice
  • 1,281
  • 2
  • 11
  • 22

2 Answers2

4

You have a classloader leak. The typical pattern goes like this.

  • You create new classloader
  • You load classes in new classloader
  • You create an instance from one of the classes.
  • You put instance into a data structure (for example) that makes it permanently reachable.
  • You discard your reference to the classloader.

The problem is that so long as the instance that you created is reachable, we need 1) the code for the instance's classes methods 2) the Class object (or the infor to make it) in case someone calls getClass() on the instance.

That means that (in effect) the class must be reachable.

But the Class has a getClassloader method, so the classloader object must also be reachable.

And a typical classloader object has internal references to all of the classes that it loaded, so they must all be reachable too.

In short, make sure that you are not keeping references to instances of classes that you loaded using the dead classloader. They will prevent the classloader from being garbage collected.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • And note that a "reference" to ClassB can simply be that ClassA has a null reference variable of type ClassB, or contains a method call that has a ClassB parameter. And there doesn't even need to be an instance of ClassA. This means that you *always* must use a find-by-name scheme for referencing ClassB from something outside of its class loader, and must always use interfaces or superclasses to reference its instances. – Hot Licks Mar 01 '15 at 13:35
  • What can cause Discard Classloader ? – Kalpak Pingle Aug 29 '16 at 05:27
  • A ClassLoader can only be garbage collected when it becomes unreachable. – Stephen C Aug 29 '16 at 06:25
1

As a followup to Stephens anser, you may want to look at this blog series of mine to learn how to track down the classloader leak. Or you may just want to skip ahead and add my Classloader Leak Prevention library to your application.

Good luck!

P.S. If you do debug it and find there is a leak within Xalan, please let me know so I can update the list of known offenders.

Mattias Jiderhamn
  • 2,053
  • 1
  • 13
  • 6