Serial Collector

## What "serial" means here Collectors differ on two axes: how many threads do the GC work, and whether application threads ("mutators") keep running during GC. The Serial collector sits at the simplest corner of both: **one** GC thread, and **zero** mutator progress while it runs. There is no concurrent phase, no parallel worker pool, no incremental work. Every collection is a single pause during which one thread does all the tracing and all the moving. That simplicity is the whole point. It has the least code, the least metadata, the fewest barriers on the application's hot paths, and the smallest native-memory footprint of any HotSpot collector. ## Young-generation collection: copying The young generation is laid out as eden plus two equal survivor spaces ("from" and "to"); only one survivor is in use at a time. Allocation is a pointer bump in eden. When eden fills, a **minor GC** (logged as an "Allocation Failure") begins: 1. All threads are brought to a safepoint. 2. The single GC thread scans the roots — thread stacks, static fields, JNI handles — plus the recorded old-to-young references, and traces the live object graph inside the young generation. 3. Every live object it finds is **copied** out: into the empty "to" survivor if it fits and is still young, or into the old generation if its age has reached the tenuring threshold or the survivor space is full. 4. Each copied object's header records an incremented age; the forwarding address of the copy is left behind so other references can be redirected to it. 5. Eden and the old "from" survivor are then declared empty in one step, the survivors swap roles, and the mutators resume. Because a copying collector touches only the *live* objects and then frees the whole region at once, its cost is proportional to survivors, not to garbage. A young generation where almost everything dies is collected almost for free — which is why minor GCs stay in the low milliseconds even single-threaded, as long as the survivor set is small. ## Old-generation collection: mark-compact When the old generation fills (or promotion fails), Serial runs a **full GC** over the entire heap using a sliding mark-compact algorithm. It marks all reachable objects, computes where each will land after compaction, rewrites every reference in the heap and in the roots to the new addresses, and then slides live objects down so they sit contiguously at the bottom of the space. Compaction rather than sweeping means the free space is one contiguous block afterwards, so subsequent allocation and promotion are simple pointer bumps and fragmentation never accumulates. The price is that all four passes run in one thread inside one stop-the-world pause, and their cost is proportional to the *live set* and the heap size being walked. ## Selecting it `-XX:+UseSerialGC` chooses it explicitly. HotSpot may also choose it for you: on a machine (or container) that fails the "server-class" test — roughly, at least two available processors and at least ~1792 MB of memory — ergonomics fall back to Serial instead of the default G1. So a JVM in a one-CPU container can be running Serial without anyone having configured it. Confirm with `-Xlog:gc` output or `java -XX:+PrintFlagsFinal -version | grep UseSerialGC`. ## What you gain and what you give up **Gain:** the smallest metadata footprint (no per-region tables, no marking bitmaps sized to the heap, no per-worker structures), the cheapest write barrier (a simple card mark), fast JVM startup, and no GC threads competing with the application for scarce CPU. On a small heap with a small live set, full GCs can complete in tens of milliseconds. **Give up:** any pause-time scalability. Pause time grows with the live set, and there is no second thread to shorten it. On a multi-gigabyte heap a full GC can take seconds, so Serial is unsuitable for latency-sensitive services with large live data. It is a deliberate choice for small, dense, or short-lived JVMs — not a general-purpose default.