Java Heap Memory Deep Dive & Garbage Collection Algorithms

This chapter provides a deep dive into Java's memory management model, focusing on the internal architecture of the Heap Memory, object lifecycle transitions, reference types, and the underlying Garbage Collection (GC) algorithms. Understanding these concepts is critical for writing highly optimized, leak-free Java applications and clearing technical system design and JVM-level interviews.

1. The Architecture of Java Heap Memory

In Java, Heap Memory is not a single, unstructured block of memory. To optimize object allocation and garbage collection, the JVM divides the Heap into distinct logical regions based on the Generational Hypothesis: most objects die young.

The Heap is divided into two primary generations:

The Young Generation

The Young Generation is where all newly created objects begin their lifecycle. Because a vast majority of objects in Java are temporary and short-lived (e.g., local variables, loop iterations, method execution contexts), this area is garbage collected frequently. It is subdivided into three spaces:

• Eden Space: The initial landing zone for all newly allocated objects. Object allocation in Eden is extremely fast.
• Survivor Spaces (S0 and S1): Two equally sized spaces (also referred to as From and To spaces) that hold objects that have survived at least one garbage collection cycle in the Eden space.

The Old Generation (Tenured)

The Old Generation contains long-lived objects that have survived multiple garbage collection cycles in the Young Generation without being dereferenced. Garbage collection in this region occurs less frequently because scanning this area is computationally expensive.

2. The Lifecycle of an Object in Heap Memory

When an object is instantiated using the new keyword, it undergoes a structured journey through the JVM's generational spaces.

Step-by-Step Promotion Flow

1. Initial Allocation: A new object is created and allocated in the Eden Space.
2. First Minor GC: As more objects are created, the Eden space eventually fills up. This triggers a Minor Garbage Collection (Minor GC).
   • Unreachable (dead) objects in Eden are cleared.
   • Surviving (live) objects are moved to Survivor Space S0.
   • Each surviving object is assigned an Age Counter (initialized to 1).
3. Subsequent Minor GCs: During the next Minor GC:
   • The Eden space and S0 are scanned.
   • Dead objects are cleared.
   • Surviving objects from both Eden and S0 are copied to Survivor Space S1.
   • The age counters of these surviving objects are incremented by 1 (making their age 2).
   • S0 is now completely empty.
4. Role Swapping (S0 <-> S1): The roles of S0 and S1 swap. On the next Minor GC, surviving objects from Eden and S1 are copied back to S0, and their ages increment. This bouncing mechanism continues, keeping the active survivor space contiguous and free of fragmentation.
5. Promotion to Old Generation: When an object's age counter reaches a specific threshold (known as the Tenuring Threshold, which defaults to 15 in many JVM configurations), it is promoted to the Old Generation.

3. JVM Promotion Optimizations & Edge Cases

The JVM does not always strictly wait for an object's age counter to reach 15 before promoting it. It dynamically optimizes memory layout using three key strategies:

A. Survivor Space Overflow

If the volume of surviving objects after a Minor GC exceeds the capacity of the target Survivor Space, the JVM immediately promotes the excess surviving objects to the Old Generation, even if their age counter is far below the threshold (e.g., age 5 or 6).

B. Dynamic Age Determination

The JVM monitors the memory footprint of objects across different ages within the Survivor spaces. If objects of a particular age (e.g., age 5) occupy more than 50% of the Survivor space (known as the Target Survivor Ratio), the JVM dynamically lowers the tenuring threshold. All objects older than this dynamically calculated age are immediately promoted to the Old Generation to prevent future survivor space exhaustion.

C. Large Object Allocation

If you allocate an exceptionally large object, such as a massive array:

// Allocating a very large array
int[] massiveArray = new int[10_000_000];

The JVM recognizes that allocating this object in the Eden space would trigger immediate garbage collection or survivor space exhaustion. To optimize performance, the JVM bypasses the Young Generation entirely and allocates this large object directly in the Old Generation.

4. Minor GC vs. Major GC

Garbage collection operations are categorized based on the generation they target:

5. End-to-End Memory Execution Walkthrough

To understand how the Stack, Heap, Method Area, and Program Counter interact, let us trace the execution of the following Java program:

class Student {
    String name;
    int age;
    static String college = "IITG";

    public Student(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void markAttendance() {
        System.out.println(name + " is present");
    }

    public static void changeCollege(String newCollege) {
        college = newCollege;
    }
}

public class Main {
    public static void main(String[] args) {
        Student s1 = new Student("Aditya", 28);
        s1.markAttendance();
        Student.changeCollege("IIT Bombay");
    }
}

Step-by-Step Execution Trace

Step 1: JVM Initialization & Class Loading

When you run java Main, the JVM starts and the Class Loader loads the Main class into the Method Area.

Step 2: Main Thread & Stack Frame Creation

The JVM creates the main execution thread. A stack frame for the main method is pushed onto the Stack Memory.

Step 3: Executing new Student("Aditya", 28)

The Program Counter points to the first line of main(). The JVM detects that the Student class is not yet loaded.

1. The Class Loader loads Student into the Method Area.
2. The static variable college is initialized. Since "IITG" is a string literal, it is allocated in the String Constant Pool (SCP) inside the Heap. The static field college in the Method Area points to this SCP address.

3. The new keyword allocates a new Student object in the Eden Space (Heap).
   • name is initialized to null.
   • age is initialized to 0.

4. The Student constructor is called, pushing a new frame onto the Stack.
   • The constructor frame contains a this reference pointing to the newly allocated Heap object.
   • It also contains local parameters: name (pointing to "Aditya" in the SCP) and age (28).

5. The constructor executes this.name = name; and this.age = age;. The instance variables of the Student object in the Heap are updated.

6. The constructor completes execution and its stack frame is popped off the Stack.
7. The reference to the Heap object is assigned to s1 in the main stack frame.

Step 4: Executing s1.markAttendance()

1. The JVM pushes the markAttendance() frame onto the Stack.
2. Since it is an instance method, it receives a this reference pointing to the Student object.

3. The method executes, reads this.name (resolving to "Aditya"), and prints "Aditya is present".
4. The frame is popped off the Stack.

Step 5: Executing Student.changeCollege("IIT Bombay")

1. The JVM pushes the static method changeCollege() frame onto the Stack.
2. Note: Because this is a static method, it does not receive a this reference.
3. The parameter newCollege points to "IIT Bombay" in the SCP.

4. The method updates the static variable college in the Method Area to point to "IIT Bombay".

5. The frame is popped off the Stack.
6. The "IITG" string literal in the SCP now has zero active references. It is eligible for future garbage collection.

Step 6: Program Termination

The main method finishes, and its frame is popped. The Stack is now empty. The reference variable s1 no longer exists, leaving the Student object in the Heap unreachable. When the GC runs, it will reclaim this object.

6. Types of References in Java

Java provides four distinct types of object references that dictate how the Garbage Collector treats those objects. They are defined in the java.lang.ref package.

A. Strong Reference

This is the default reference type in Java. An object is protected from garbage collection as long as it is reachable via a chain of strong references.

// Strong Reference
Student s1 = new Student("Aditya", 28); 

B. Soft Reference

Soft references are ideal for memory-sensitive caches. The JVM will keep softly referenced objects alive as long as there is plenty of memory, but will aggressively reclaim them before throwing an OutOfMemoryError.

import java.lang.ref.SoftReference;

// Creating a Soft Reference
Student strongRef = new Student("Aditya", 28);
SoftReference<Student> softRef = new SoftReference<>(strongRef);

// Break the strong reference
strongRef = null; 

// Retrieve the object
Student cachedStudent = softRef.get(); 
if (cachedStudent != null) {
    // Cache Hit
    cachedStudent.markAttendance();
} else {
    // Cache Miss (GC reclaimed it due to low memory)
}

C. Weak Reference

Weak references do not prevent their referent from being made eligible for garbage collection. They are automatically cleared during the next GC cycle.

import java.lang.ref.WeakReference;

// Creating a Weak Reference
Student strongRef = new Student("Aditya", 28);
WeakReference<Student> weakRef = new WeakReference<>(strongRef);

strongRef = null; // Break the strong reference

// Force GC (Request)
System.gc(); 

// Retrieve the object
Student student = weakRef.get(); // Will return null because GC has run

D. Phantom Reference

Phantom references are used to track when an object has been finalized and is ready to be reclaimed. Unlike Soft and Weak references, calling .get() on a Phantom reference always returns null. It is used in conjunction with a ReferenceQueue to perform low-level resource cleanup.

7. Garbage Collection Algorithms Explained

The Garbage Collector relies on specific algorithms to identify and reclaim dead objects.

1. Mark and Sweep Algorithm

This algorithm operates in two distinct phases:

• Mark Phase: The GC starts from the root references (Stack, Static variables) and traverses the entire object graph. Every reachable object is marked as "live".
• Sweep Phase: The GC scans the heap memory linearly. Any memory address containing an unmarked object is cleared and added to a free list.

The Fragmentation Problem: Because objects are deleted from their original positions without reorganizing the remaining objects, memory becomes highly fragmented. This can prevent the allocation of a new, large contiguous object even if the total free memory is sufficient.

2. Mark and Compact Algorithm

To solve the fragmentation problem, this algorithm adds a compaction step:

• Mark Phase: Identifies and marks all live objects.
• Compact Phase: Shifts all surviving objects to the beginning of the heap space, creating a contiguous block of active memory. The remaining memory is marked as free.
• Trade-off: While it prevents fragmentation, updating all reference addresses to point to the relocated objects adds significant CPU overhead.

3. Copying Algorithm

This algorithm is designed specifically for the Young Generation (S0/S1):

• It divides the available memory space into active and inactive regions.
• When the active region fills up, the GC copies only the live objects to the inactive region in a contiguous block.
• The entire active region is then wiped clean in a single operation.
• This is highly efficient for the Young Generation because the number of surviving objects is typically very small.

8. The "Stop the World" (STW) Phenomenon & Parallel GC

A fundamental characteristic of Java Garbage Collection is the Stop-the-World (STW) pause.

Why Must the Application Stop?

During garbage collection, the GC must scan the object graph and potentially move objects in memory (e.g., during Compacting or Copying phases). If the application threads (mutators) were allowed to run concurrently during this process, they could:

• Create new objects.
• Modify existing references, causing the GC to miss live objects and accidentally delete them.
• Attempt to access an object at an old memory address while the GC is relocating it.

To prevent this data corruption, the JVM pauses all application threads during GC execution.

Sequential vs. Parallel GC

• Sequential GC: Uses a single thread to perform garbage collection. This results in long STW pauses, making it unsuitable for high-performance applications.
• Parallel GC: Uses multiple threads to perform garbage collection concurrently. While it still pauses the application, the multi-threaded execution significantly reduces the duration of the STW pause.

9. Real-World Debugging: OutOfMemoryError, System.gc(), and Heap Dumps

The Fallacy of System.gc()

Java allows developers to suggest garbage collection using the following call:

System.gc(); // Requesting JVM to run Garbage Collector

Warning: Calling System.gc() does not guarantee that the JVM will run the Garbage Collector. It is merely a hint or request. The JVM may ignore this call if it determines that running a GC cycle at that moment is unnecessary or too expensive. Relying on this method in production code is a bad practice.

Memory Leaks & java.lang.OutOfMemoryError

A memory leak occurs when objects that are no longer needed by the application remain reachable through active references (e.g., forgotten static collections, open database connections, or unclosed thread locals). Over time, these objects fill the Heap, eventually causing the JVM to crash with:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Analyzing Memory with Heap Dumps

When troubleshooting memory leaks, developers use a Heap Dump—which acts as a complete snapshot of the Heap memory at a specific point in time.

Generating a Heap Dump via CLI

You can configure the JVM to automatically generate a heap dump when an OutOfMemoryError occurs:

java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps/app_oom.hprof -jar App.jar

Analyzing with VisualVM

Once you have the .hprof file, you can load it into tools like VisualVM or Eclipse Memory Analyzer (MAT) to:

1. Identify which class instances are consuming the most memory.
2. Trace the path of references keeping those objects alive (finding the root cause of the leak).
3. Inspect active threads and their local variables at the moment of the crash.

Summary and Key Takeaways

• Generational Architecture: The Java Heap is divided into the Young Generation (Eden, S0, S1) for short-lived objects and the Old Generation for long-lived objects.
• Object Promotion: New objects are allocated in the Eden space. Surviving objects bounce between S0 and S1, incrementing their age counter. Once they reach the tenuring threshold (default 15), they are promoted to the Old Generation.
• Bypassing the Young Gen: The JVM optimizes large allocations (like massive arrays) by placing them directly in the Old Generation to avoid copying overhead.
• Minor vs. Major GC: Minor GC cleans the Young Generation frequently and quickly. Major GC cleans the Old Generation less frequently but is much slower and more expensive.
• Reference Strengths: Java supports Strong (never collect if reachable), Soft (collect on low memory), Weak (collect on next GC), and Phantom (used for post-mortem cleanup) references.
• GC Algorithms: The JVM utilizes Mark-Sweep (causes fragmentation), Mark-Compact (eliminates fragmentation but is slow), and Copying (fast, used in Young Gen) algorithms.
• Stop-the-World (STW): All application threads are paused during GC to ensure data consistency and prevent reference modification during memory reorganization.
• Memory Diagnostics: Never rely on System.gc(). Instead, use JVM flags to capture Heap Dumps (.hprof files) on failure and analyze them using tools like VisualVM to locate memory leaks.