GC Fundamentals: Mark-Compact, Copying, and Mark-Sweep

Garbage collection sounds like magic until you hit a 10-second pause and suddenly you want to know exactly what the JVM is doing under the hood. The three foundational GC algorithms - Mark-Sweep, Mark-Compact, and Copying - each take a different approach to the same problem: finding dead objects and reclaiming their memory. Once these click, every garbage collector in the JVM starts making sense - including why your application just froze for 10 seconds.

Introduction

Garbage collection sounds like magic until you hit a 10-second pause and suddenly you need to know exactly what the JVM is doing under the hood. The three foundational GC algorithms — Mark-Sweep, Mark-Compact, and Copying — each take a different approach to solving the same problem: finding dead objects and reclaiming their memory without leaving dangling pointers or fragmenting the heap. Once you understand how each algorithm works and what trade-offs it makes, every garbage collector in the JVM starts making sense — including why your application just froze for 10 seconds.

The JVM uses different algorithms for different heap generations based on object lifetimes. Most objects die young — allocated and collected before they ever need promoting to old gen. A fast copying collector on the young generation handles the majority of garbage cheaply. Objects that survive long enough get promoted to old generation, which uses mark-compact collection because those objects stick around and need to be collected infrequently. This is the generational hypothesis in practice, and it is why understanding the individual algorithms matters.

This guide walks through Mark-Sweep, Mark-Compact, and Copying in detail: their phases, their performance characteristics, and when each algorithm is the right choice. You will learn why fragmentation is the key tradeoff — Mark-Sweep is fast but fragmented, Mark-Compact eliminates fragmentation but has the longest pauses, and Copying has the fastest allocation but wastes 50% of heap space. Understanding these fundamentals gives you the vocabulary and mental model for reading GC logs, choosing a GC algorithm, and diagnosing GC-related performance problems.

When to Use This Knowledge

Use when:

• Debugging GC pause issues or throughput problems
• Choosing or tuning a garbage collector for a specific workload
• Reading GC logs and trying to make sense of the phases
• Understanding why certain objects are collected while others are not

Do not use when:

• Writing application code that does not deal with memory directly
• Using a managed runtime that abstracts GC entirely (some languages do this well)

When NOT to Use

Understanding GC algorithm internals is overkill for most developers. If you are building web applications, REST APIs, or business logic that does not involve custom memory management, Mark-Compact versus Copying details rarely matter. Most GC languages like Python, JavaScript, Go, or Java with a properly tuned collector handle this for you.

Managed cloud runtimes and serverless environments abstract GC entirely. AWS Lambda, Google Cloud Functions, and similar platforms manage memory for you and do not expose JVM tuning flags. In these environments, knowing that Mark-Sweep leaves fragmentation behind does not help you write better code. The platform configures GC, and you cannot change it.

Serverless functions with tight memory limits also rarely benefit from GC knowledge. The platform may kill your function before it accumulates enough garbage to trigger a significant pause. Algorithm trade-offs do not change the constraints you are operating under.

How Garbage Collection Works: The Big Picture

Every GC algorithm has to solve three problems:

1. Find live objects - trace from GC roots (stack, static fields, JNI references)
2. Reclaim dead objects - free memory that is no longer reachable
3. Keep memory usable - avoid fragmentation so future allocations succeed

Different algorithms solve these in different ways, with different trade-offs around speed, memory overhead, and pause times.

Mark-Sweep Algorithm

Mark-Sweep is the simplest algorithm. It operates in two phases:

graph LR
    A["Phase 1: Mark"] --> B["Phase 2: Sweep"]
    A --> C["Traverse from GC roots"]
    A --> D["Mark all reachable objects"]
    B --> E["Sweep unreachable objects"]
    B --> F["Add to free list"]

Phase 1: Mark

The collector starts from GC roots (thread stacks, static fields, JNI handles) and traverses the object graph. Every object it reaches gets marked. At the end of this phase, every reachable object has a mark bit set.

Phase 2: Sweep

The collector scans the entire heap. Any object without a mark bit is unreachable and its memory gets reclaimed. The free memory is added to a free list (or similar structure) for future allocations.

Key Characteristics

Aspect	Behavior
Memory overhead	Low - just one mark bit per object
Pause time	Long - must scan entire heap during mark AND sweep
Fragmentation	High - free memory is scattered
Allocation speed	Slower over time - free list lookup can be costly
Cache behavior	Poor - objects far apart in memory

Why Mark-Sweep Alone Is Rarely Used in Production

Mark-Sweep leaves the heap fragmented. After many cycles, free memory exists as scattered islands. Allocating a large object may fail even though total free memory is plenty, just because nothing is big enough to hold it contiguously.

The JVM uses Mark-Sweep internally (as part of Mark-Compact), but no major GC runs pure Mark-Sweep on the old generation.

Mark-Compact Algorithm

Mark-Compact extends Mark-Sweep with a compaction phase that eliminates fragmentation.

graph LR
    A["Mark"] --> B["Sweep"] --> C["Compact"]
    C --> D["Slide live objects to one end"]
    C --> E["Update all object references"]
    C --> F["Single contiguous free block"]

Phase 1: Mark

Same as Mark-Sweep - trace reachable objects and mark them.

Phase 2: Sweep

Same as Mark-Sweep - identify unreachable objects.

Phase 3: Compact

This is where Mark-Compact differs from Mark-Sweep. The collector slides all live objects toward one end of the heap, eliminating gaps. All references to moved objects are updated. The result is a single contiguous block of free memory at the far end.

Compact Phase Details

Compacting is expensive because:

• Every live object’s location changes
• Every reference to those objects must be updated (including stack frames, other object fields, and static fields)
• The collector must update the object table that maps old addresses to new addresses

graph TB
    subgraph Before["Before Compact"]
        O1["Object A"]
        O2["Object B"]
        F1["Free"]
        O3["Object C"]
        F2["Free"]
        F3["Free"]
    end
    subgraph After["After Compact"]
        O1A["Object A"]
        O2A["Object B"]
        O3A["Object C"]
        F4["Free (contiguous)"]
    end

    Before --> After

Key Characteristics

Aspect	Behavior
Memory overhead	Low - same as Mark-Sweep
Pause time	Longest - adds compaction on top of mark and sweep
Fragmentation	None - heap is defragmented
Allocation speed	Fast after compact - big contiguous block
Throughput	Lower than Copying due to compaction cost

Copying Algorithm

Copying (also called evacuation or scavenge) avoids fragmentation entirely by using two equal-sized spaces called from-space and to-space.

graph TB
    subgraph Semispace["Semispace Copying"]
        direction LR
        From["From-Space"] -->|"Live objects copied"| To["To-Space"]
        To -->|"Roles swap"| From2["From-Space (next GC)"]
    end

How It Works

1. Objects start in from-space
2. When from-space is full (or on every minor GC), the collector copies all reachable objects to to-space, one by one
3. Objects are copied densely, filling to-space with no gaps
4. The roles of from-space and to-space swap for the next collection

Hot Spots in Copying

Copying collectors optimize by tracking where the next object should go (a “free pointer”). New allocations simply advance this pointer. This makes allocation essentially free - no free list lookup, no fragmentation.

// Allocation with semispace copying - simplified
Object allocate(int size) {
    if (freePointer + size > toSpaceEnd) {
        triggerGC(); // not enough room
    }
    Object result = freePointer;
    freePointer += size;
    return result;
}

Key Characteristics

Aspect	Behavior
Memory overhead	High - needs two equal spaces (only 50% usable)
Pause time	Short - copying is faster than scanning + compacting
Fragmentation	None
Allocation speed	Very fast - bump-the-pointer allocation
Throughput	High for young gen where most objects die
Old gen suitability	Poor - copying old objects is expensive

The Generational Twist

Copying collectors shine when paired with generations. Most objects die young - allocated and collected before they ever need promoting. A fast copying collector on the young generation handles the majority of garbage cheaply. Objects that survive long enough get promoted to old generation, which uses Mark-Compact.

Trade-off Table

Aspect	Mark-Sweep	Mark-Compact	Copying
Memory overhead	Low	Low	High (50%)
Pause time	Moderate	Longest	Shortest
Throughput	Moderate	Lower	Highest
Fragmentation	High	None	None
Allocation speed	Moderate	Fast (after compact)	Very fast
Old gen suitability	Some	Best	Poor
Young gen suitability	Some	Some	Best
Complexity	Low	High	Moderate

Production Failure Scenarios

1. Premature Old Generation Fill

Symptom: Frequent Full GC events even with plenty of young generation space.

Cause: Objects being promoted too quickly (premature promotion) fill the old generation faster than Full GC can reclaim space.

Solution: Increase Survivor spaces with -XX:SurvivorRatio or reduce the tenuring threshold. Monitor promotion rates with jstat -gc.

2. Fragmentation-Induced Allocation Failure

Symptom: OutOfMemoryError: Heap Space with heap dump showing significant free memory.

Cause: Pure Mark-Sweep or poor compaction strategy leaving fragmented free memory.

Solution: Switch to a collector with better compaction (G1, ZGC, Shenandoah). Increase heap if possible.

3. Long GC Pauses

Symptom: Application freezes for seconds during Old Generation collection.

Cause: Mark-Compact running on a large heap with many live objects. Compaction requires updating references everywhere.

Solution: Use a low-pause collector (G1, ZGC, Shenandoah) or reduce heap size and optimize object retention.

Implementation Snippets

Reading GC Logs

Enable verbose GC logging to see which algorithm phases are running:

-Xlog:gc*:file=gc.log

A typical Serial GC log entry (old generation collection) shows mark, sweep, and compaction phases:

[Full GC (Allocation Failure)  16384K->8192K(16384K), 0.1234567 secs]

The Allocation Failure means the old generation could not accommodate a promotion, triggering a Full GC.

Forcing a GC with jcmd

# Force a full GC and print result
jcmd <pid> GC.run

Checking GC Algorithm in Use

import java.lang.management.*;
import java.util.*;

public class GCInfo {
    public static void main(String[] args) {
        List<GarbageCollectorMXBean> gcBeans = ManagementFactory.getGarbageCollectorMXBeans();
        for (GarbageCollectorMXBean gc : gcBeans) {
            System.out.println("GC Name: " + gc.getName());
            System.out.println("  Collection count: " + gc.getCollectionCount());
            System.out.println("  Collection time: " + gc.getCollectionTime() + "ms");
            System.out.println("  Memory pools: " + Arrays.toString(gc.getMemoryPoolNames()));
        }
    }
}

Observability Checklist

• Enable GC logging with -Xlog:gc*:file=gc.log
• Use jstat -gc <pid> to monitor heap usage per space
• Track jstat -gc columns FGCT (Full GC time) and GCT (Total GC time)
• Generate heap dump before and after GC: jmap -dump:file=before.hprof <pid>
• Use Java Flight Recorder to capture GC events with -XX:StartFlightRecording
• Monitor promotion rate from Young to Old with generational sizing tools
• Watch for compaction overhead by comparing GCC (GC count) vs FGCC (Full GC count)

Security Notes

1. GC Logging can reveal application behavior patterns - protect gc.log files
2. Heap Dumps from production can expose sensitive data - sanitize before sharing
3. JMX Access to GC MBeans should be restricted to authorized monitoring systems
4. Memory Access via JVMTI can inspect/modify heap - secure agent attachments

Common Pitfalls / Anti-Patterns

Pitfall	What happens	Fix
Assuming Full GC means compaction	Serial/Parallel GC may do mark-sweep without compacting	Use -XX:+UseG1GC or -XX:+UseZGC
Ignoring young gen sizing	Frequent minor GC or premature promotion	Tune -Xmn or -XX:NewRatio
Using Copying on old gen	Objects copied unnecessarily, high memory churn	Use Mark-Compact based GC for old gen
Setting heap too small	Frequent GC of any type	Profile and size correctly
Assuming GC solves memory leaks	Leaked objects accumulate in old gen	Use heap dumps and profiling to find leaks

Quick Recap Checklist

• Mark-Sweep = Mark + Sweep (fast but fragmented)
• Mark-Compact = Mark + Sweep + Compact (no fragmentation but longest pause)
• Copying = Copy between two spaces (fast allocation, 50% memory overhead)
• Copying works best on young gen where most objects die
• Mark-Compact works best on old gen where objects stick around
• Fragmentation causes allocation failures even with free memory available
• GC algorithm choice directly impacts pause times and throughput
• No single algorithm is best for all generations - JVM uses different ones for each

Interview Questions

Further Reading

• HotSpot Virtual Machine Garbage Collection Tuning Guide - Oracle’s official comprehensive GC tuning guide
• Java GC Handbook - Preventing GC Pauses - Practical strategies for minimizing GC pauses in production
• Understanding Java Garbage Collection Logging - How to read and interpret GC logs effectively
• Generational GC and Object Aging - Deep dive into how objects age across generations

Conclusion

Mark-Sweep, Mark-Compact, and Copying are the three foundational GC algorithms, each solving the same problem (finding dead objects, reclaiming memory) with different trade-offs: Mark-Sweep is fast but fragmented, Mark-Compact eliminates fragmentation but has longest pauses, Copying is fastest for young gen but wastes 50% memory. The JVM uses Copying for young generation (where most objects die) and Mark-Compact for old generation (where objects stick around).