Java: Garbage Collection

Garbage Collector: For any application performance is a very important part. If your application is not utilizing memory and other resources available in efficient manner, it may result in poor performance or in some cases crashing the application. So, memory management is very important, unlike other languages c, c++ etc, java doesn’t leave memory management to the developer which is a very tedious and error prone task. Java provides garbage collector program. Which helps developer to assign memory to objects when the created and release it when objects are not in use. Java garbage collection provides multiple algorithms for performing allocation/de-allocation memory. And developer can choose as per the requirements. Reason behind providing multiple algorithm can be understood by following performance measures.

1.    Responsiveness: Responsiveness refers to how quickly an application or system responds with a requested piece of data. Examples include:

·       How quickly a desktop UI responds to an event

·       How fast a website returns a page

·       How fast a database query is returned

For applications that focus on responsiveness, large pause times are not acceptable. The focus is on responding in short periods of time.

2.    Throughput: Throughput focuses on maximizing the amount of work by an application in a specific period. Examples of how throughput might be measured include:

·       The number of transactions completed in a given time.

·       The number of jobs that a batch program can complete in an hour.

·       The number of database queries that can be completed in an hour.

High pause times are acceptable for applications that focus on throughput. Since high throughput applications focus on benchmarks over longer periods of time, quick response time is not a consideration.

Before discussing about the algorithms available for garbage collection in java, we should understand different segments of Heap Memory.

Heap memory can be divided into 3 parts major parts.

1.    Young Generation: Young Generation occupied almost 40% area of total heap, and it can be further divided into three segments.

·       Eden space: All the newly created objects goes to the eden space area. Most of the objects who lost the reference also found here so whenever gc runs, they cleaned up from here only. When this space is filled up to a limit Minor GC run to reclaim unused memory.

·       Survivor-0: After minor gc runs into eden space area, survived objects moved to Survivor-0 space.

·       Survivor-1: After minor gc runs into eden space area, survived objects moved to Survivor-0 space.

When objects moved from eden space to survivor spaces, gc keeps one survivor completely empty. If ti found that both survivor space holding objects, it moved object from one survivor to another to keep one empty.

2.    Old Generation: The Old Generation is used to store long surviving objects. Typically, a threshold is set for young generation object and when that age is met, the object gets moved to the old generation. Eventually the old generation needs to be collected. This event is called a major garbage collection. Major garbage collection are also Stop the World events. Often a major collection is much slower because it involves all live objects. So, for Responsive applications, major garbage collections should be minimized. Also note, that the length of the Stop the World event for a major garbage collection is affected by the kind of garbage collector that is used for the old generation space.

3. Permanent Generation: The Permanent generation contains metadata required by the JVM to describe the classes and methods used in the application. The permanent generation is populated by the JVM at runtime based on classes in use by the application. In addition, Java SE library classes and methods may be stored here. Classes may get collected (unloaded) if the JVM finds they are no longer needed and space may be needed for other classes. The permanent generation is included in a full garbage collection.

1. Newly objects are allocated to eden space.

2. When eden space fills up, minor gc triggered.

3. Objects survived the minor gc moved to first survivor space.

4. At the next minor GC, the same thing happens for the eden space. Unreferenced objects are deleted, and referenced objects are moved to a survivor space. However, in this case, they are moved to the second survivor space (S1). In addition, objects from the last minor GC on the first survivor space (S0) have their age incremented and get moved to S1. Once all surviving objects have been moved to S1, both S0 and eden are cleared. Notice we now have differently aged object in the survivor space.

5. At the next minor GC, the same process repeats. However, this time the survivor spaces switch. Referenced objects are moved to S0. Surviving objects are aged. Eden and S1 are cleared.

6. This slide demonstrates promotion. After a minor GC, when aged objects reach a certain age threshold (8 in this example) they are promoted from young generation to old generation.

7. As minor GCs continue to occure objects will continue to be promoted to the old generation space.

8. So that pretty much covers the entire process with the young generation. Eventually, a major GC will be performed on the old generation which cleans up and compacts that space.

Garbage Collector Algorithms:

The Serial GC:

The serial collector is the default for client style machines in Java SE 5 and 6. With the serial collector, both minor and major garbage collections are done serially (using a single virtual CPU). In addition, it uses a mark-compact collection method. This method moves older memory to the beginning of the heap so that new memory allocations are made into a single continuous chunk of memory at the end of the heap. This compacting of memory makes it faster to allocate new chunks of memory to the heap.
To enable the Serial Collector use:
-XX:+UseSerialGC
The Parallel GC:
The parallel garbage collector uses multiple threads to perform the young generation garbage collection. By default, on a host with N CPUs, the parallel garbage collector uses N garbage collector threads in the collection. The number of garbage collector threads can be controlled with command-line options:
-XX:ParallelGCThreads=<desired number>
On a host with a single CPU the default garbage collector is used even if the parallel garbage collector has been requested. On a host with two CPUs the parallel garbage collector generally performs as well as the default garbage collector and a reduction in the young generation garbage collector pause times can be expected on hosts with more than two CPUs. The Parallel GC comes in two flavors.

To enable the Serial Collector use:

-XX:+UseParallelGC

The Concurrent Mark Sweep (CMS): The Concurrent Mark Sweep (CMS) collector (also referred to as the concurrent low pause collector) collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads. Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects. If fragmentation becomes a problem, allocate a larger heap.
Note: CMS collector on young generation uses the same algorithm as that of the parallel collector.
To enable the CMS Collector use:
-XX:+UseConcMarkSweepGC
and to set the number of threads use:
-XX:ParallelCMSThreads=<n>
The Garbage First or G1 garbage collector:
The Garbage First or G1 garbage collector is available in Java 7 and is designed to be the long-term replacement for the CMS collector. The G1 collector is a parallel, concurrent, and incrementally compacting low-pause garbage collector that has quite a different layout from the other garbage collectors described previously. However, detailed discussion is beyond the scope of this OBE.

To enable the G1 Collector use:

-XX:+UseG1GC