Wednesday, July 9, 2014

Heap management in JAVA

Heap is the important concept for analyzing performance of Java application and to understand the details of Heap we need to understand how JVM uses the system memory. In JVM memory can be divided into following categories

  • -          Heap memory
  • -          Non Heap memory
  • -          Other (JVM code, internal structure etc.)
The Java heap space is the run time data area from which the JVM allocates memory for all of the Java application's objects and arrays. So when we create any object in JAVA we are basically creating that object in the heap area. From the performance testing point of view Java heap space is the most frequently tuned feature of a JVM, and is configured with the -Xms -Xmx command line options. 
One of the important points to remember here is maximum heap size we can define for 32 bit OS is 4 GB while that for 64 GB is 32 GB.
Non Heap memory stores per class structures like runtime constant pool, field and method data, and the code for methods and constructors, as well as interned Strings.
Unfortunately, the only information JVM provides on non-heap memory is its overall size. No detailed information on non-heap memory content is available.
Coming back to Heap memory, we can consider Heap to be divided into two categories:
-          Eden and tenured.
Initially all objects gets created in Eden space. Once GC is called objects which are not required or referenced any more gets deleted and still referenced objects are move to survivor area with in Eden space and objects which survive the GC on survivor area are moved to tenured area. We have this division to have better memory management and performance.  As there are various objects with different life cycle – Some objects remain live throughout the application while some objects die very soon. That is the reason we system provide different categories inside heap. Performing a GC on tenured area is more expensive then the Eden area.





Sizing the heap memory is a critical decision which should be taken based on the application. If we sized the heap memory to be large then during GC application may become unresponsive as JVM would be busy in doing the GC on large amount of memory also if we specify Heap to be less, throughput could be impacted due to increases in call for GC and can lead to “Out of memory exceptions”





No comments: