Understanding JVM Heap Spaces

JVM Heap memory is divided in to two main categories: young generation space and old generation space. As the names imply, young generation space is meant for recently created objects and old generation space stores surviving objects that have lived to some extent.

Young generation space is itself divided into three categories:

· Eden space and

· Two survivor spaces.

The JVM initially allocates objects in the Eden space, where most objects die and quickly are reclaimed. When Eden space fills up, it causes the JVM to perform a minor collection, when it moves some surviving objects to the old generation. (Note: Any new objects created inside the method go into Eden space and the objects space is reclaimed once the method exists. Class-level object variables hang around for the entire life of the objects.)

The two survivor spaces are for copying live objects, allowing young objects to remain in the young generation space longer. One survivor space is empty at any given time. It serves as the destination of the next copying collection of any living objects in the Eden space and the other survivor space

Old/Tenured generation space:

If objects get too old, or young generation space gets filled up, JVM promotes objects to the old generation space. When the old generation space gets filled up, the JVM performs a major collection (even FGC some times) to remove the unused objects and reclaim their space. A major GC collection takes a significant amount of time and can affect system performance. Therefore, developers must make sure that major collections do not happen too often in their applications.  Depending on the GC algorithm, if there is no enough tenured space and young gen space movement has to happen the GC alg. attempts a Full GC which scans across the complete heap and perm generation also..(In a fast mem leaking case, after certain threshold, u should see a change in steady and constant frequency FGC to a very frequent FGC happening and ultimately resulting in OOM.. )

Third generation – Permanent generation – A non heap memory

There is a third generation too - Permanent Generation. The permanent generation is special because it holds meta-data describing user classes (classes that are not part of the Java language). Examples of such meta-data are objects describing
classes and methods and they are stored in the Permanent Generation. Applications with large code-base can quickly fill up this segment which will cause java.lang.OutOfMemoryError: PermGen no matter how high your -Xmx and how much memory you have on the machine.

Sun JVMs allow you to resize the different generations of the heap, including the permanent generation. On a Sun JVM (1.3.1 and above) you can configure the initial permanent generation size and the maximum permanent generation size.

To set a new initial size on Sun JVM use the -XX:PermSize=64m option when starting the virtual machine. To set the maximum permanent generation size use -XX:MaxPermSize=128m option. If you set the initial size and maximum size to equal values you may be able to avoid some full garbage collections that may occur if/when the permanent generation needs to be resized. The default values differ from among different versions but for Sun JVMs upper limit is typically 64MB.

Native memory pool - A non heap memory

Ther is also one more component of memry of jvm that is called native memory pool which is used for compiling code and storing native code