Fundamentals 10 min read

Understanding JVM Garbage Collectors: Evolution, G1 Overview, and Practical Use Cases

This article explains the evolution of JVM garbage collectors from Serial to G1, details the different collector types, describes G1's memory model and collection phases, and outlines scenarios where G1 provides low‑latency, high‑throughput garbage collection for large Java applications.

Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
Understanding JVM Garbage Collectors: Evolution, G1 Overview, and Practical Use Cases

01 JVM Garbage Collector Evolution

Before JDK 1.3.1 only the Serial collector was available; it is single‑threaded and pauses all application threads during collection.

The Parallel collector introduced multithreaded collection to improve throughput.

CMS (Concurrent Mark‑Sweep) performs minor GC with a pause, while Full GC runs in background threads.

G1 (Garbage‑First) aims to reduce pause times for large heaps (greater than 4 GB) and lowers fragmentation compared to CMS.

02 Types of JVM Garbage Collectors

Young‑generation collectors: Serial (first generation), ParallelNew (second generation), Parallel Scavenge (third generation), G1 (fourth generation).

Old‑generation collectors: Serial Old (first generation), Parallel Old (second generation), CMS (third generation), G1 (fourth generation).

03 G1 Collector Overview

G1 was added in JDK 7, focuses on low pause times and large‑heap support, and is intended to replace CMS.

Key features: region‑based heap, mark‑compact algorithm, controllable pause time, and better parallelism.

Improvements over CMS include a different marking algorithm, pause‑time control, and more effective use of multiple CPU cores.

Differences: G1 uses regions instead of traditional generations, merges free memory after collection, and can collect both young and old regions.

Suitable scenarios: multi‑CPU servers with heap >4 GB, applications that generate a lot of fragmentation, and cases where predictable GC pauses are required.

04 G1 Heap Memory Model

Pre‑G1 memory model: Young generation (Eden + two Survivor spaces), Old generation, and either PermGen (pre‑JDK 8) or Metaspace (JDK 8+).

G1 divides the heap into many equal‑sized regions (default 2048 regions). Each region is marked as Eden, Survivor, Old, or Humongous for objects larger than 50% of a region size.

05 G1 Collection Process

Phases:

Initial Mark (STW) – pauses all application threads and marks objects directly reachable from GC roots.

Concurrent Mark – performs a full‑heap reachability analysis in parallel with the application.

Final Mark – marks objects that became reachable during the concurrent phase.

Cleanup – selects regions to reclaim based on the expected pause‑time target.

Young GC or Mixed GC – both are STW; Mixed GC also reclaims selected old regions.

06 G1 GC Modes

Young GC collects Eden and Survivor regions.

Mixed GC also collects a subset of old regions, allowing control over pause time while avoiding a full old‑generation collection.

G1 does not have a native Full GC; when a full heap scan is required, Serial Old is invoked.

07 Recommended Use Cases for G1

G1 is ideal for applications that need low GC latency (<0.5 s) with large heaps (6 GB or more) and stable pause times.

Switch from CMS or Parallel Old when full GC pauses are long or frequent, allocation rates are high, or pause times exceed 0.5‑1 s.

If your current collector meets performance requirements, staying with it is acceptable; upgrading the JDK alone does not necessitate moving to G1.

JavaJVMperformanceMemory ManagementGarbage CollectionG1
Mike Chen's Internet Architecture
Written by

Mike Chen's Internet Architecture

Over ten years of BAT architecture experience, shared generously!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.