What events cause a JVM to start a young (minor) collection, and what causes it to fall back to a full collection of the whole heap?

## The general rule: collection is allocation-driven A tracing collector does not run on a timer or because "there is garbage". It runs because an **allocation cannot be satisfied**, or because a heuristic predicts that it soon will not be. Everything below is a refinement of that idea. ## Young (minor) collection Object allocation is normally a pointer bump inside a thread-local allocation buffer carved out of the young space's Eden area. Fast path: bump the pointer, done. When the buffer is exhausted, the thread asks for another; when Eden itself cannot supply one, allocation *fails*, and that failure is the trigger for a **young collection**. The collection traces from the roots plus the remembered set that records old-to-young references, evacuates the surviving young objects into a survivor area or promotes older ones, and leaves Eden empty. Consequences worth stating in an interview: - **Frequency = allocation rate / usable young size.** Doubling the young generation roughly halves the number of young collections for the same allocation rate. - **Cost ≈ the surviving live set**, not the garbage. Dead objects cost nothing to collect in a copying collector — they are simply not visited. This is why a high allocation rate of short-lived objects can be surprisingly cheap. ## Old generation and full collections Several distinct events push work into the old generation or into a whole-heap collection, and being able to name them separately is what distinguishes a middle answer from a junior one. **1. Promotion / evacuation failure.** A young collection needs somewhere to put survivors that are old enough or that do not fit in a survivor area. If the old generation cannot accept them, the young collection fails partway. The recovery is expensive — typically a stop-the-world full collection, and in region-based collectors an evacuation failure with objects left in place. **2. Occupancy threshold starting a concurrent cycle.** Mostly-concurrent collectors do not wait until the old generation is full: they begin a concurrent marking cycle when occupancy crosses an initiating threshold, so that reclamation completes before space runs out. Modern collectors adapt this threshold from observed allocation rates. If marking plus reclamation cannot outrun allocation, the collector runs out of room and falls back to a stop-the-world full collection — the classic "concurrent mode failure" shape. **3. Class-metadata pressure.** Class metadata lives outside the Java heap and has its own threshold. Reaching it triggers a collection whose purpose is to unload unreachable classes and their loaders. An application that generates classes at run time — dynamic proxies, scripting engines, repeated redeployments — can drive collections this way even with a nearly empty Java heap. **4. Explicit requests.** `System.gc()` and `Runtime.getRuntime().gc()` request a collection. Two important non-obvious callers: direct `ByteBuffer` allocation invokes it when it cannot reserve native memory (hoping to run cleanup for unreachable buffers), and some RMI/distributed-GC machinery schedules it periodically. `-XX:+DisableExplicitGC` ignores such requests, and there are flags to service them with a concurrent cycle rather than a full stop-the-world collection. **5. Allocations that cannot use the normal path.** An object too large for the young space — a very large array — is allocated directly into the old generation or into dedicated humongous regions. If space for it cannot be found, that allocation itself triggers collection, potentially a full one. **6. Tooling and management operations.** Requesting a heap dump or invoking a diagnostic that requires a clean heap typically performs a full collection first. ## What the low-latency collectors change Collectors designed around very short pauses replace "collect when full" with **allocation-rate-driven pacing**: they start a cycle early enough that reclamation is predicted to finish before the heap fills, sometimes on a timer as well. Their failure mode is not a long pause but an **allocation stall** — threads are throttled or blocked until memory becomes available — or, at the extreme, a degenerate or full collection fallback. So on those collectors the diagnostic question shifts from "why is the full GC so long" to "why did the cycle start too late or run too slowly". ## Reading it operationally - Frequent young collections with a low survivor count are normal and often cheap; the lever is young size versus allocation rate. - Repeated full collections are almost always one of: live set genuinely near heap size (fix the leak or raise the heap), concurrent cycle starting too late (start it earlier), promotion pressure from objects surviving young collections in bulk, or an explicit `System.gc()` caller. - A collection with an empty-looking Java heap points at metadata or an explicit trigger, not at heap pressure.