BrewlearnGenerational GC in Java
Young (eden, survivors) and old generations; minor vs major collections.
Most objects die young
Look at a web request: temporary strings, iterators, DTOs, lambdas. Almost all of it is garbage milliseconds later. This weak generational hypothesis is why collectors split the heap into a young and an old generation.
The young generation
New objects are allocated in Eden. A minor GC collects only the young generation: it copies the few live objects into a survivor space, where they age with each GC they survive. There are two survivor spaces, used in turns.
What about the dead?
Eden holds 1 GB, but only 5 MB of it is still alive. What does the minor GC do with the 995 MB of dead objects?
Think about it, then reveal the answer
Nothing at all. It copies the 5 MB of live objects out, then simply reuses the whole Eden for new allocations. A copying collector's cost depends on the live objects, not the dead ones.
Promotion
Each survived young GC increases an object's age. Past the tenuring threshold, it's promoted (tenured) into the old generation. Minor GCs are frequent and cheap; major/full GCs also process the old generation and are rarer and costlier.
Long-lived cache entry
A cache entry survives dozens of young collections. Where does it end up?
The old generationMetaspaceDeleted to make room
Show the answer
It's promoted to the old generation. Metaspace holds class metadata, not objects, and the GC never deletes reachable objects.
Picturing two big boxes
Don't imagine the young and old generations as two contiguous blocks. G1, the default collector, splits the heap into many equal-sized regions. Each region is Eden, survivor, old or humongous, and a region's role can change over time.
Reading GC logs
Frequent, short young pauses are healthy. Trouble starts with medium-lived objects: a cache that keeps entries just long enough to be promoted, then drops them. They fill the old generation and trigger the expensive collections. Shorter lifetimes or a better eviction policy often help more than a bigger heap.
Key takeaways
- Young gen = Eden + two survivor spaces
- Objects that survive enough GCs are promoted to old gen
- Minor GC cost depends mostly on live objects, not dead ones
- G1 divides the heap into many equal-sized regions
💡 A nursery and a retirement home: most toddlers' toys are thrown out quickly, and only what lasts moves to the long-term shelf.
G1 treats any object of at least half a region's size as "humongous" and gives it its own contiguous regions, straight in the old generation.
Practice questions
Why is a minor GC usually cheap, even with a large Eden?
- It skips objects created in the last second
- Its cost depends on the few live objects it copies, and most young objects are already dead
- It never moves objects
- It only runs while the app is idle
Check your answer
Its cost depends on the few live objects it copies, and most young objects are already dead. A copying young collector evacuates only live objects; dead ones cost nothing because their space is simply reused.
An object keeps surviving young collections. What eventually happens to it?
- It is promoted (tenured) to the old generation
- It moves to metaspace
- It is moved to the thread stack
- It is deleted to make room
Check your answer
It is promoted (tenured) to the old generation. Each survived young GC increases the object's age. Past the tenuring threshold it is copied into the old generation.