How does G1 GC work?

Hook: Interviewers like this question because G1 looks simple on paper, but it reveals whether you understand how modern Java keeps pauses under control.

Question: How does G1 GC work?

Answer: G1, short for Garbage-First, is a region-based garbage collector that splits the heap into many small regions instead of treating it like one big block. It tries to keep pauses short by collecting the regions with the most garbage first, using mostly concurrent background work plus brief stop-the-world evacuation pauses. It is a generational collector, so it handles young objects frequently and old objects in selected mixed collections when that gives the best payoff.

Interview-Ready Answer: I’d explain G1 as a region-based, mostly concurrent, generational GC. The heap is split into equal-sized regions, usually 1 to 32 MB, and G1 first does concurrent marking to find where the garbage is, then during a pause it evacuates the regions with the most reclaimable space first. That gives it a way to aim for a pause target, like the default 200 ms from -XX:MaxGCPauseMillis, instead of chasing only throughput. On modern server JVMs, it has been the default collector since Java 9.

What G1 is trying to solve

G1 stands for Garbage-First. Its main job is to reduce long stop-the-world pauses on medium and large heaps by working on the regions that give the best payoff first. The heap is split into many equal-sized regions, usually between 1 MB and 32 MB, and the JVM chooses the size automatically based on heap size.

How it works under the hood

1. Split the heap into regions. Each region can be young, old, or humongous. A humongous object is bigger than 50% of a region, so the JVM stores it across one or more special regions.
2. Track cross-region references. When an application thread, called the mutator, writes a reference, G1 uses a write barrier, a tiny piece of extra code on the write path, to record which regions point into which other regions. That information is stored in a remembered set, or RSet, which lets G1 avoid scanning the whole heap.
3. Do young collections first. Most objects die young, so G1 frequently pauses, copies the live objects out of young regions, and immediately reclaims the empty regions. This copying step is called evacuation. Live objects are moved to empty regions, so the collected region can be reused all at once.
4. Run concurrent marking. When old occupancy rises, G1 starts a concurrent marking cycle. Concurrent means the JVM does most of the work while the application keeps running. G1 uses SATB, snapshot-at-the-beginning, which means it marks the heap as if it were frozen at the moment marking started, even though the program keeps mutating objects.
5. Finish with a short stop-the-world remark. G1 briefly pauses to complete the mark, clean up bookkeeping, and find which old regions have a lot of garbage. This is one of the few required pauses in the concurrent cycle.
6. Do mixed collections. After marking, G1 can collect young regions plus selected old regions with the highest garbage density. This is the garbage-first part: it spends the next pauses on the regions that are easiest to pay off.
7. Fallback when things get tight. G1 tries to keep some free regions in reserve so it has space to copy live objects during evacuation. If the reserve is too small, or if many humongous objects and long-lived references make copying too expensive, G1 can miss its pause goal or fall back to a Full GC.

When and why to use it

Use G1 when you want a good balance of throughput and predictable pauses, especially for services with large heaps and latency-sensitive requests. It is often a strong default for backend systems, cache-heavy services, and mixed workloads. If your main goal is maximum throughput for batch jobs, Parallel GC can still win; if your goal is ultra-low latency, newer collectors like ZGC or Shenandoah may be better.

G1 vs other collectors

Performance and edge cases

• Pause cost: roughly proportional to the live data in the selected regions, not the whole heap.
• Concurrency overhead: concurrent marking and remembered-set maintenance consume CPU in the background, so G1 trades some throughput for smoother latency.
• Space overhead: G1 needs metadata per region plus remembered sets and a free-region reserve, so memory overhead is higher than the simplest collectors.
• Realistic tuning knob: -XX:MaxGCPauseMillis is a goal, not a promise. The default goal is 200 ms, and the JVM will do its best, but it may miss under heavy allocation pressure.
• Gotcha: G1 is not fully concurrent. The evacuation pauses are still stop-the-world, so they stop application threads briefly while objects are copied.

Real-World Story: Imagine an e-commerce checkout service running with a 32 GB heap. Most requests create short-lived cart and pricing objects, so G1 is a good fit: young regions die quickly, and pauses stay short enough that checkout latency stays stable. One day, a team adds a cache of full request payloads but forgets to remove old entries, so long-lived objects start piling up in old regions.

At first, the logs show repeated Pause Young (Mixed) events, which means G1 is trying to reclaim both young and selected old regions. Then the mixed collections stop reclaiming much memory because the cache keeps those objects alive, and the JVM starts spending more CPU on marking and remembering cross-region pointers. Users see checkout slowdowns, then timeouts, and the logs may eventually show longer pauses or even To-space exhausted messages when G1 cannot find enough free regions to evacuate live objects safely. The bug is not that G1 is broken; it is that the object graph stayed live for too long, so the collector had less and less garbage to profitably remove.

Follow-up & Tricky Questions:

• Why is it called Garbage-First? Because G1 picks the regions with the highest garbage density first, so each pause gets the biggest memory payoff.
• What is a remembered set? It is per-region metadata that records incoming references from other regions, so G1 can find live objects without scanning the whole heap.
• What is the difference between young GC and mixed GC? Young GC collects only young regions, while mixed GC collects young regions plus selected old regions that G1 believes are cheap to reclaim after concurrent marking.
• What is a humongous object? It is an object larger than 50% of a region, so G1 allocates it specially across one or more regions instead of moving it like normal objects.
• Why can G1 still do a Full GC? If evacuation runs out of free regions, or the heap becomes too fragmented for the current workload, the JVM may fall back to a stop-the-world Full GC as a rescue path.
• Is G1 completely concurrent? No. Marking is mostly concurrent, but evacuation pauses and remark pauses are still stop-the-world, which is why G1 improves pause predictability rather than eliminating pauses.
• Does G1 always beat Parallel GC? No. For pure throughput workloads or small heaps, Parallel GC can be faster because it has less bookkeeping and can spend more time doing useful work.
• Is -XX:MaxGCPauseMillis a hard guarantee? No. It is a goal that guides G1’s heuristics, but real allocation pressure and object lifetimes can make the JVM miss the target.

• Gotcha: G1 only collects young objects. Wrong. After concurrent marking, it also performs mixed collections that include selected old regions.
• Gotcha: G1 never stops the world. Wrong. It still has stop-the-world pauses for young evacuation, remark, and sometimes Full GC.
• Gotcha: a lower pause target always means a better JVM. Wrong. An aggressive target can reduce throughput because G1 may need to do more frequent, smaller collections.

Common Mistakes

• Calling G1 fully concurrent. Correction: only some of its work is concurrent; evacuation still happens in stop-the-world pauses.
• Saying it scans the whole heap every time. Correction: G1 uses regions, remembered sets, and marking to avoid full-heap scanning on every pause.
• Thinking the pause target is a guarantee. Correction: -XX:MaxGCPauseMillis is a heuristic goal, not a hard deadline.
• Forgetting mixed collections. Correction: after marking, G1 can reclaim old regions with lots of garbage, not just young ones.

Memory Hook

Memory Hook: Think of G1 as a warehouse clerk who always cleans the messiest shelves first, one shelf at a time, instead of shutting down the whole warehouse.

Cheat Sheet

• Heap is split into regions, not one big space.
• G1 is generational: young collections are frequent.
• Concurrent marking finds old garbage in the background.
• Mixed GC collects young plus garbage-rich old regions.
• -XX:MaxGCPauseMillis is a goal, default 200 ms.
• Humongous objects are special and can be awkward for G1.

Practice Tasks

• Run a Java app with G1 and inspect GC logs to spot young, mixed, and remark pauses.
• Add a memory leak with a long-lived static reference and observe how old regions stop becoming collectible.
• Compare the same workload under G1 and Parallel GC to see the latency versus throughput trade-off.