Generational Collection¶
Partitioned policy — instantiates Reachability-Guided Resource Reclamation
Partitions resources by age and collects the short-lived young generation often and cheaply, scanning the long-lived old generation only rarely.
Generational Collection is not a way of deciding reachability but a way of scheduling the decision by age. It rests on an empirical regularity — most resources die very young, and the few that survive infancy tend to live a long time.[n1] So it splits the resource universe into generations, keeps freshly created resources in a small "young" region, and reclaims that region frequently and cheaply; the rare survivors are promoted into an older region that is examined only occasionally. The payoff is that the collector spends almost all of its effort where almost all of the garbage is, and almost none re-examining stable, long-lived resources. Its defining move is the age partition and the promotion rule that moves survivors across it — everything else is bookkeeping around that stratification.
Example¶
A long-running Java order-processing service allocates a torrent of short-lived objects — request buffers, parsed messages, temporary collections — nearly all of which are dead within milliseconds of the request finishing. Under the HotSpot JVM's generational collector, these land in the young generation. A minor collection runs whenever the young region fills; because it only has to look at young objects, it completes in a few milliseconds and reclaims the overwhelming majority of them. An object that somehow survives a handful of minor collections — a cache entry, a pooled connection — has proven it is not ephemeral, so it is promoted to the old generation, which is collected far less often. Over an hour the service might run hundreds of quick minor collections and only a couple of expensive old-generation ones. The scheduler never asked "is this object reachable?" any differently; it asked it far more often for young objects than old ones.
How it works¶
New resources are allocated into the youngest generation. Each collection cycle constitutes an epoch: resources that survive a cycle have their age incremented, and once age crosses a tenuring threshold they are promoted to the next generation. Minor collections process only the young generation; to do so safely they treat references into the young generation from older ones as extra entry points, tracked in a "remembered set" updated as inter-generational references are written. Major collections, which reclaim the old generation, are triggered rarely. The reclamation schedule — frequent-and-cheap versus rare-and-expensive — is thus keyed entirely to age.
Tuning parameters¶
- Young/old size ratio — a larger young region makes minor collections rarer but longer and lets more objects die before promotion; a smaller one collects more often and promotes sooner.
- Tenuring threshold — how many epochs a resource must survive before promotion. Too low promotes soon-to-die objects into the expensive-to-collect old generation; too high wastes effort copying survivors repeatedly.
- Generation count — two is standard; more generations refine the age gradient at the cost of more remembered-set bookkeeping.
- Minor/major cadence — how much old-generation pressure it takes to trigger a full collection, trading old-generation footprint against major-pause frequency.
When it helps, and when it misleads¶
Its strength is leverage: when most resources really do die young, a small, frequent, cheap collection reclaims most of the garbage with tiny pauses, and stable data is left undisturbed. It misleads exactly when its founding assumption fails. A workload of medium-lived objects — alive long enough to survive minor collections but not truly long-lived — defeats it: those objects get promoted just before dying, so they accumulate as garbage in the old generation where collection is rare and costly. This premature promotion inflates old-generation occupancy and can drive punishing major-collection pauses. The classic misuse is sizing the young generation too small, so ordinary request-scoped objects tenure and the old generation thrashes. The guarding discipline is to monitor promotion rate and old-generation occupancy, and to resize the young region so that ephemeral objects die before they are ever promoted.
How it implements the components¶
candidate_reclamation_set— the young generation is the standing candidate pool; each minor collection targets that region rather than the whole universe.synchronization_and_epoch_rule— generations advance by collection epochs, and the age-crosses-threshold promotion rule is what moves a resource from one region to the next.reclamation_policy— an age-stratified schedule: collect the young often and cheaply, the old rarely and thoroughly.
It does not recompute a full-universe reachable_closure_record on every cycle — that whole-graph trace is tracing_mark_sweep_cycle's, and generational collection deliberately avoids it via the remembered set — nor does it define the resource_universe_boundary its major collection ultimately relies on.
Against its nearest twin tracing_mark_sweep_cycle: that mechanism traces the whole universe uniformly each cycle; this one partitions by age and, on a routine cycle, scans only the young generation under an epoch-and-promotion rule the uniform tracer has no notion of.
Related¶
- Instantiates: Reachability-Guided Resource Reclamation — supplies an age-keyed schedule that concentrates reclamation effort where garbage actually is.
- Consumes: tracing_mark_sweep_cycle — the rare major collection of the old generation is a full reachability trace over that region.
- Sibling mechanisms: reference_counting · concurrent_collection_barrier · cycle_detection_pass · dry_run_reclamation_report · lease_expiry_sweep · reachability_graph_visualization · tombstone_then_delete · weak_reference_registry
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Generational Collection operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it partitions resources by age and collects the short-lived young generation often and cheaply, scanning the long-lived old generation only rarely.
Independent corroboration: The frozen evidence defines Generational Collection as 'Partitions resources by age and collects the short-lived young generation often and cheaply, scanning the long-lived old generation only rarely', so its operative form is Control, Automation & Runtime.
Nearest alternative: Structure, Architecture & Configuration — Young and old partitions, remembered sets, and tenure thresholds execute as an automated runtime collection policy; their memory topology enables it.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Generational garbage collection follows the computing-specific weak generational hypothesis about object lifetimes.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] The weak generational hypothesis — the empirical observation, robust across many workloads, that most objects die young while a small minority live long. It is the load-bearing assumption of every generational collector and the thing to check when one underperforms. ↩