HotSpot JVM Heap Memory and Garbage Collection

The JVM runtime environment uses a large memory pool called the heap, for object allocation. The JVM automatically starts garbage collections (GC) to clean up the heap of unreferenced or dead objects.

In contrast, memory management in legacy programming languages such as C++ is left to the programmer. If the JVM heap settings are not set correctly, the garbage collection overheads can make the system appear unresponsive. In the worst case, your transactions or the JVM may abort due to outOfMemory exceptions.

Garbage collection techniques are constantly being improved. For example, the Sun JVM supports a "stop-the-world" garbage collector where all the transactions have to pause at a safe point for the entire duration of the garbage collection. The Sun JVM also supports a parallel concurrent collector, where transactions can continue to run during most of the collection.

The Sun heap and HP heap are organized into generations to improve the efficiency of their garbage collection, and reduce the frequency and duration of user-perceivable garbage collection pauses. The premise behind generational collection is that memory is managed in generations or in pools with different ages. The following diagram illustrates the layout of the generational heap.

At initialization, a maximum address space is virtually reserved, but not allocated, to physical memory unless it is needed. The complete address space reserved for object memory can be divided into young and tenured (old) generations.

New objects are allocated in the Eden. When the Eden fills up, the JVM issues a scavenge GC or minor collection to move the surviving objects into one of the two survivor or semi spaces. The JVM does this by first identifying and moving all the referenced objects in the Eden to one of the survivor spaces. At the end of the scavenge GC, the Eden is empty (since all the referenced objects are now in the survivor space) and ready for object allocation.

The scavenge GC's efficiency depends on the amount of referenced objects it has to move to the survivor space, and not on the size of the Eden. The higher the amount of referenced objects, the slower the scavenge GC. Studies have, however, shown that most Java™ objects live for a short time. Since most objects live for a short time, one can typically create large Edens.

Referenced objects in the survivor space bounce between the two survivor spaces at each scavenge GC, until it either becomes unreferenced or the number of bounces have reached the tenuring threshold. If the tenuring threshold is reached, that object is migrated up to the old heap.

When the old heap fills up, the JVM issues a Full GC or major collection. In a Full GC, the JVM has to first identify all the referenced objects. When that is done, the JVM sweeps the entire heap to reclaim all free memory (for example, because the object is now dead). Finally, the JVM then moves referenced objects to defragment the old heap. The efficiency of the Full GC is dependent on the amount of referenced objects and the size of the heap.

The HotSpot JVM sets aside an area, called permanent generation, to store the JVM's reflective data such as class and method objects.