Understanding HotSpot VM Garbage Collectors (GC) in Depth

Since its introduction in 1995, Java has evolved substantially. So, too, have Java Virtual Machines (JVMs). The integration of JIT compilers, complex and sophisticated GCs, and improvements in JVM runtime environments have allowed developers to meet and improve their performance requirements.

One of the challenges introduced by modern JVMs is that developers consider it a black hole, which can make it difficult to improve app performance. Hence, a basic understanding is needed.

HostSpot VM - What Is It?

The JVM is, by definition, a virtual machine: a software machine that simulates what a real machine does. Like real machines, it has an instruction set, a virtual computer architecture, and an execution model. It is capable of running code written with this virtual instruction set, pretty much like a real machine can run machine code.

HotSpot is an implementation of the JVM concept, originally developed by Sun and now owned by Oracle. There are other implementations of the JVM specification, like JRockit and IBM J9, among many others.

There are three major HotSpot components:

• VM Runtime

• JIT Compiler

• Memory Manager

HotSpot VM Internal Architecture

The HostSpot VM architecture supports the ability to realize high performance and massive scalability. For example, the JIT compilers make dynamic code optimizations while the app is running and generate high-performance native machine instructions targeted at the underlying system architecture, and the multithreaded garbage collector (GC) helps yield high scalability.

HotSpot VM Garbage Collectors

The JVM specification dictates that any JVM implementation must include a garbage collector to reclaim unused memory. The behavior and efficiency of GC can heavily influence the performance/responsiveness of the application.

Generational Garbage Collection

The HotSpot VM uses generational garbage collection, a well-known garbage collection method in which the heap is divided into two physical areas referred to as generations:

• Young generation: The most recently allocated objects are allocated to this generation, which, compared to the heap, is small and collected frequently. Since it is collected quickly, the number of objects that survive to the next generation is small. The young generation consists of the eden space and the two survivor space. The eden space has the most newly allocated objects. This space will almost be empty after a minor GC. The two survivor space has objects that have survived at least one minor GC but have been given one chance of becoming unreachable before getting promoted to the older generation.

• Old generation: Objects that are longer-lived or not collected are moved to this space.  This generation is larger than the young generation and typically grows at a slower rate. 

• Permanent generation: Even though it's called a generation, it is not part of the generation hierarchy. It is used by the HotSpot VM itself to hold metadata such as class data structures, interned strings, etc. 

HotSpot VM Garbage Collectors

HotSpot has different types of garbage collectors, each targeted at a different set of applications. 

Serial GC

In this type, both minor and the full garbage collection take place in a stop-the-world fashion. This means the application threads will be stopped while the collector is running. Only after the collection is finished is the application resumed.

In this mark-compact garbage collector, it first identifies which objects are still alive in the old generation. It then slides them towards the beginning of the heap in a single contiguous chunk at the end of the heap. 

It takes only one virtual processor for garbage collection. Its popular use is the on the machines where there are a large number of JVMs available. 

Parallel GC

As the name implies, it uses multiple VM threads to perform the garbage collection. It also executes in a stop-the-world fashion.

Applications that require a high rate of throughput can benefit from this GC. Also, batch processing engines, scientific computing, etc. are all well suited for parallel GC. 

Mostly Concurrent GC

In this type, the young generation is managed the same way as SC and PC GCs. Its old generation, however, is managed by an algorithm that manages most of its work concurrently, imposing only two short pauses per garbage collection.  

The Garbage-First GC (G1)

The G1 is a parallel, concurrent, and incrementally compacting low-pause GC. It uses a different heap layout compared to the other GCs. It splits the heap into equal-sized chunks called regions. Though G1 is generational, it does not have sperate regions for young and old generations. Instead, each generation is a set of regions, which allows resizing of the young generation in a flexible way.  

G1 gets its name is because it goes after the region with the most garbage objects in it. 

Comparisons Between GCs

Hope you enjoyed this. Cheers!