Why is PermGen space growing?

Question

I\'ve read a few articles, and I understood the following (please correct me and/or edit the question if I\'m wrong):

The java heap is segmented like this:

Answer 1

This is one of the more annoying problems to debug. There are a lot of reasons you could be seeing growing permgen use. Here are 2 links I found very useful in both understanding how leaks happen as well as tracking down what is causing them.

http://frankkieviet.blogspot.com/2006/10/how-to-fix-dreaded-permgen-space.html

http://frankkieviet.blogspot.com/2006/10/classloader-leaks-dreaded-permgen-space.html

Answer 2

The most common causes I've seen are:

1. Java classes are loaded
2. JAXBContext.newInstance
3. String.intern()

Answer 3

The most common causes I've seen are:

• Custom classloaders that don't carefully free up older classes after loading new ones.
• Classes remaining in PermGen after redeploying an application multiple times (more common in Dev than Prod)
• Heavy use of Proxy classes, which are created synthetically during runtime. It's easy to create new Proxy classes when an a single class definition could be reused for multiple instances.

Answer 4

Actually, in Sun's JVM Permanent Generation (PermGen) is completely separate from the heap. Are you sure you aren't looking at the Tenured Generation? It would be suspicious indeed if your Permanent Generation kept growing.

If your perm gen IS growing constantly, it is a difficult area to dig into. Generally it should grow when new classes are loaded for the first time (and potentially certain uses of reflection could also cause this). Interned strings are also stored in perm gen.

If you happen to be on Solaris, you could use jmap -permstat to dump out perm gen statistics, but that option does not appear to be available on Windows (and potentially other platforms). Here is the documentation on jmap for Java 6

From Sun's guide on JConsole (which will let you view the size of these pools):

For the HotSpot Java VM, the memory pools for serial garbage collection are the following.

• Eden Space (heap): The pool from which memory is initially allocated for most objects.
• Survivor Space (heap): The pool containing objects that have survived the garbage collection of the Eden space.
• Tenured Generation (heap): The pool containing objects that have existed for some time in the survivor space.
• Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
• Code Cache (non-heap): The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.

Answer 5

Are you doing something funky with the classloader chain? Are you calling intern() on a bunch of strings?

Answer 6

This is a very common problem when you are manipulating the classloader. This is seen a lot in Java EE apps when you are redeploying hibernate/cglib. For more info check out

http://opensource.atlassian.com/confluence/spring/display/DISC/Memory+leak+-+classloader+won%27t+let+go