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:
Young Generation: objects that are created go here, this part is frequently and inexpensively garbage collected
Old Generation: objects that survive the garbage collections of the Young generation go here, this area is garbage collected less frequently and using a more CPU demanding process/algorithm (I believe it's called mark-sweep)
Edit: as stated by another user, PermGen is not a part of the region called heap
- PermGen: this area is filled of your app classes metadata and many other things that do not depend on the application usage.
So, knowing this... why does my PermGen space grows when the app is under heavy load? For what I said before this space should not incrementally fill in spite of the app load, but as I said in the beginning probably I'm wrong about some assumptions.
In fact if the PermGen space is growing, is there a way of garbage collect or reset it?
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.
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.
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
Are you doing something funky with the classloader chain? Are you calling intern() on a bunch of strings?
If you are working with Java EE application it's probably a classloader leak.
you might find the following additional links to be useful:
http://www.zeroturnaround.com/blog/rjc201/
http://www.ibm.com/developerworks/java/library/j-dclp3/index.html
The most common causes I've seen are:
- Java classes are loaded
- JAXBContext.newInstance
- String.intern()
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
