WhiteHedge Blog

Hi, I hope everyone knows about most important but ignored part of the JVM is memory management i.e. GC, Garbage Collector that runs behalf of user application. I will present a brief about how GC is being allocated and works, here.

Normally when you run any application without any memory specific parameters to JVM on start-up, it will take his own defaults, and that works fine unless you are doing some fancy things in your code which will blow up memory quickly… JVM allocates heap space to default or user specified. Allocation of heap is arranged as follows

Note that the part which is mentioned as virtual is not being actually allocated but kept reserved, if required.

As you see above total heap size is divided as three major parts

There are normally two threads run for garbage collections, first one is lightweight and runs on Young/Eden generation it is called Young GC. Another one is major and runs on Old/Tenured generation it is also called as Full GC it traverse entire heap and sweep the space. If your FGC takes more than 98% of time in sweeping the memory and could hardly reclaim 2% of memory you will get out of memory error.

The Java HotSpot VM includes three different collectors, each with different performance characteristics.

• The serial collector is a single thread garbage collection, it is relatively efficient and best-suited to single processor machines. It can be explicitly enabled with the option -XX:+UseSerialGC.
• The parallel collector (also called throughput collector) used for minor collections in parallel, which can significantly reduce garbage collection overhead. It can be explicitly enabled with the option -XX:+UseParallelGC. New compaction feature is added in J2SE5 onwards that allows to perform major collections also in parallel. New Parallel compaction is enabled by adding the option -XX:+UseParallelOldGC .
• The concurrent collector runs on concurrent threads with application running, It is designed to keep garbage collection pauses short. It is useful with medium- to large-sized data sets applications for which response time is more important than overall throughput, It can be enabled with the option -XX:+UseConcMarkSweepGC.

OutofMemoryError is thrown when there is insufficient space to allocate object or your GC is unable to make space available even after sweep, this error do not necessarily imply that there is memory leak, it may be due to insufficient  space allocation at time of configuration of heap for an application. Whenever we get this error try to address it be getting its more information provided along with it.

• Java heap space: This indicates that an object could not be allocated in the heap. Young and Old space is already full. Possible causes would be 1) The issue may be just a configuration problem 2) it could be your application code which might creating some heavy objects/loading large data in memory 3) It also can be possible that your heap is keeping reference of objects that are not need to be referenced for long time (i.e. memory leak) or 4) It can be excessive use of finalizers by the application. This error can be fixed with maximum heap size specified by the –Xmx command line option.
• PeremGen space: This indicates that the permanent generation is full. As described earlier that this is the area of the heap where the JVM stores its metadata of classes. If an application loads a large number of classes you will get this error, then the permanent generation may need to be increased. You can do so by specifying the command line option –XX:MaxPermSize=n, where n specifies the size.
• Requested array size exceeds VM limit: This indicates that the application attempted to allocate an array that is larger than the heap size. For example, if an application tries to allocate an array of 512MB but the maximum heap size is 256MB, then this error will be thrown. In most cases the problem is likely to be either that the heap size is too small or that a bug results in the application attempting to create an array whose size is calculated to be incorrectly huge.

 In second part I will explain more details how heap allocation works and what the parameters available for tuning GC are.

References for detail readings:

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom