skip to content

questions

page 1 of 2

A managed heap split into a young area and an older area rests on what observation about object lifetimes?

level: juniorimportance: must knowfreq 68%

answer

  1. about lifetimes, not sizes
  2. the age distribution is lopsided
  3. collect where garbage is dense
  4. a nursery swept often and cheaply
  5. the hypothesis the split is named for

basics

~20 s

Most objects die very young — the weak generational hypothesis. Splitting the heap by age lets a collector sweep the young area often and cheaply, where almost everything is already garbage, and touch the older area rarely.

solid answer

~40 s

The split rests on the **weak generational hypothesis**: object lifetimes are extremely lopsided, so the great majority of allocations become unreachable very soon after they are created, while a small minority live a long time. A tracing collector's work is set by what is still live, not by what it reclaims, so the cheapest place to collect is the region with the most garbage in it — the newest allocations. New objects therefore go into a young area collected very often, survivors are aged and eventually promoted into a mature area collected rarely. A second, weaker claim usually travels with it: references from older objects into younger ones are comparatively rare, which is what makes recording those references affordable.

go deeper

for a junior

Be able to state the observation in one sentence — most objects die very young — and say that the young area is therefore collected often and the older area rarely. That sentence alone is a pass at a first screen.

for a middle

Explain why a skewed lifetime distribution is exploitable at all: a tracing collector pays for survivors, not for garbage, so concentrating collections where garbage is densest reclaims the most space per unit of work.

for a senior

Show the other side of the ledger. Name the write record for references from the older area, the copying that promotion costs, and the fact that the expensive collection is deferred rather than removed.

for a principal

Frame it as a bet on a workload's allocation profile. Be ready to say what evidence would show the bet is losing on a given service, and that the fix usually lies in what the program retains rather than in the collector.

## The split A generational heap divides allocated memory into at least two areas. Every new object is created in the **young area**, often called the nursery. An object that has survived some number of young-area collections is moved — **promoted** — into the **mature area**. The two areas are collected on separate schedules, and usually with different algorithms: the young area very often, the mature area rarely. ## The observation that justifies it The **weak generational hypothesis** states that the distribution of object lifetimes in real programs is heavily skewed: the great majority of allocations become unreachable very soon after they are created, while a small minority stay reachable for a long time, often for the rest of the process's life. The short-lived population is the scaffolding of ordinary work: - intermediate values produced while parsing, formatting or transforming data; - temporary collections built inside one call and discarded when it returns; - per-unit-of-work objects in a service — a decoded message, its validation result, the buffers used to compose a reply. The long-lived population is small and mostly created once: - configuration, routing tables and other structures built during start-up; - caches and pools that are deliberately retained; - connection and session state that outlives an individual unit of work. A second, weaker claim is usually paired with it: references **from** older objects **to** younger ones are comparatively rare. That claim matters because it is what makes the bookkeeping for cross-area references affordable. Neither claim is a law. Both are empirical observations that hold across a wide range of application and service workloads and fail for others. ## Why a lopsided distribution is worth exploiting A tracing collector's work is proportional to what is **live**, not to what is garbage. It starts from roots, follows references, and touches each reachable object it finds. Unreachable objects are never visited individually; their space is recovered wholesale once the live ones have been accounted for. Three consequences follow: 1. The best region to collect is the one with the highest **garbage density**, because the work is set by the survivors while the payoff is set by the dead. 2. By the hypothesis, the young area has the highest garbage density in the heap — commonly only a few percent of it is live when the collector arrives. 3. Collecting the whole heap every time would pay to trace the mature area's large live set in order to reclaim mostly the same young garbage. | | young area | mature area | |---|---|---| | collected | very often | rarely | | typical survival | a small percentage | most of it | | cost driver | survivors copied | live set traced | | space reclaimed per unit of work | large | small | | pause | short | long | ## What the split costs Nothing here is free, and an interviewer will expect the other side of the ledger: - **A write record.** Collecting the young area alone means not tracing the mature area, so a reference from a mature object to a young one would be invisible. Such writes are recorded as they happen so the collector can treat their targets as extra roots. - **Promotion machinery.** Survivors must be aged and eventually moved, and moving them means copying bytes and fixing up the references that point at them. - **A deferred bill.** The mature area still fills and still has to be collected. The split changes how often the expensive collection runs, not whether it is needed. - **Extra footprint.** Space has to be reserved for survivors and for the area they age in. ## Where the observation fails The split stops paying when a large share of ongoing allocation survives: - a cache or buffer pool that keeps most of what it allocates; - per-request state deliberately retained across requests; - a workload whose unit of work runs long enough that its objects are still live whenever the young area is collected. In those cases each young collection copies a great deal and promotes a great deal, so the program pays the cost of the split and receives little of the benefit. The remedy is usually on the program's side — retain less, or give the young area enough room that a unit of work finishes inside one collection interval — rather than in the choice of algorithm. ## What an interviewer is listening for That you name **lifetime**, not size or type, as the property the heap is partitioned by; that you connect it to the rule that collector work tracks live data; and that you can name a workload for which the hypothesis is false.

  • Does the split make long-lived garbage easier to reclaim?
    No. Once an object is promoted, its space is held until a mature-area collection runs, and those are deliberately rare. The split makes short-lived garbage cheap to reclaim and leaves long-lived garbage to a collection that is bigger and less frequent — a deferral, not a saving.
  • Why is the heap partitioned by age rather than by object size?
    Because size predicts neither lifetime nor the cost of collection per byte reclaimed, and age predicts both. Placement by size is a separate concern: some designs do handle very large objects specially, to avoid copying them or to avoid fragmenting the young area, but that is an allocation decision rather than the argument for generations.

saying these in an interview costs you the question

  • Thinks the heap is split by object size rather than by age
  • Says the young area holds small objects and the older area large ones
  • Believes the split pays off on every workload, whatever it retains
  • Assumes an object moves to the older area after a fixed elapsed time
  • Claims the collector must scan the whole heap anyway, so the split saves nothing
open as a page

In a tracing garbage collector, what is a root, and why must a collection start from the root set?

level: juniorimportance: must knowfreq 68%

basics

~20 s

A root is a reference the collector can find without tracing anything first — a running thread's stack slot or register, a global table entry, a handle registered by code outside the collected heap. Everything the program can still touch starts at one of them.

open as a page

In three-colour marking (white unreached, grey reached but unscanned, black scanned), why may no black object reference a white one?

level: middleimportance: must knowfreq 58%

basics

~20 s

Black means already scanned, so the marker will not revisit it on its own. A reference from a black object to a white one is therefore a live object the trace never reaches — and would wrongly reclaim.

open as a page

When a collector splits one heap trace into many short increments, what does the running program experience instead of one long stop?

level: middleimportance: must knowfreq 62%

basics

~20 s

Many brief suspensions rather than one long one. The collector marks a bounded slice of the heap, hands control back, and resumes later from where it stopped. The longest pause shrinks; total collection work usually grows.

open as a page

Why does adding heap headroom above a service's live set make a tracing collector cheaper per allocated byte?

level: middleimportance: must knowfreq 58%

basics

~20 s

Tracing cost follows the live set, not the free space, while each cycle reclaims everything above the live set. Extra headroom therefore spreads the same tracing work over far more allocation before the next cycle is needed.

open as a page

Why can a tracing collector not deliver short pauses, high throughput and a small heap all at once?

level: middleimportance: must knowfreq 66%

basics

~20 s

Collection work is paid in one of three currencies: spare memory, application throughput, or pause time. Buying one corner spends another - spare heap makes cycles rarer, and a tight pause target adds barrier work to ordinary program execution.

open as a page

Why is a mature-area collection so much more expensive per byte reclaimed than a young-area collection of the same size?

level: middleimportance: must knowfreq 55%

basics

~20 s

Survival rate decides it. A tracing collector pays for live objects, not for garbage, so a young area that is a few percent live reclaims almost all of itself for very little work, while a mature area that is mostly live traces a great deal to reclaim little.

open as a page

Why can a tracing collector not reclaim an object that your program will never read again?

level: middleimportance: must knowfreq 64%

basics

~20 s

Because it decides liveness by reachability, not by usefulness: if any chain of references from a root still leads to the object, it stays. Whether the program will ever read it again is not a property the collector can compute.

open as a page

After a trace finishes, why does the sweep phase's cost grow with total heap size while copying survivors does not?

level: middleimportance: must knowfreq 58%

basics

~20 s

Sweeping walks every block in address order, live and dead alike, to rebuild the free list, so its cost tracks heap size. Evacuation follows references and copies only survivors, so its cost tracks the live set, not the garbage.

open as a page

In a tracing collector, what does holding an object only through a weak reference change about when it is reclaimed?

level: middleimportance: must knowfreq 60%

basics

~20 s

A weak reference is not a path that keeps its target alive. Once no strong path reaches the object, the collector is free to reclaim it and to clear the weak reference, which then reads as empty.

open as a page

Why is a hook that runs when an object is collected an unreliable place to release a scarce operating-system handle?

level: seniorimportance: must knowfreq 56%

basics

~20 s

Collection is triggered by memory pressure, not by handle pressure. A small object guarding a scarce handle creates almost no pressure, so the handle pool can run dry while the heap is still comfortable and the hook has not run.

open as a page

Why is it safe for a concurrent marker's write barrier to shade an object grey that turns out to be garbage?

level: middleimportance: should knowfreq 44%

basics

~20 s

Marking is allowed to err in one direction only. Keeping a dead object costs a cycle's worth of memory and is collected next time, while freeing a live one corrupts the program — so barriers over-approximate liveness on purpose.

open as a page

Why does a write record for old-to-young references usually mark a fixed-size heap block rather than the exact field that was written?

level: middleimportance: should knowfreq 40%

basics

~20 s

Cost on the hot path. A reference store happens constantly, so the record is made as cheap as a shift and a byte write: mark the block containing the field dirty. Precision is paid back later, by scanning dirty blocks for references into the young area.

open as a page

You clear one reference into a large object graph and the next collection frees nothing — why?

level: middleimportance: should knowfreq 45%

basics

~20 s

Liveness is the transitive closure over the whole root set: an object survives if any path from any root still reaches it. Clearing one edge frees only what that edge was the sole path to.

open as a page

In a cache whose keys are held weakly so entries drop out by themselves, why must a stored value never reference its own key?

level: middleimportance: should knowfreq 45%

basics

~20 s

The table holds its values strongly, so a value that points back at its own key keeps that key strongly reachable. The weak key is then never cleared, the entry never leaves, and the cache grows without bound.

open as a page

A collector relocates a live object while the program runs. How does a thread still holding the old address avoid using the stale copy?

level: seniorimportance: should knowfreq 44%

basics

~20 s

The old location keeps a forwarding record pointing at the copy, and a read barrier on reference loads detects it, follows it, and writes the corrected reference back into the slot it came from, so the program only ever works on the current copy.

open as a page

Why is a service's mean garbage-collection pause a poor predictor of what its slowest requests experience?

level: seniorimportance: should knowfreq 48%

basics

~20 s

Pauses are rare and arrive whole. They miss most requests entirely and land in full on a few, so an average spreads a concentrated cost evenly and describes nobody's experience; the tail keeps the concentration users actually feel.

open as a page

Why does tightening a service's garbage-collection pause target usually cost application throughput rather than coming free?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Short pauses come from doing collection alongside the running program, which puts a check on the program's own reference accesses, repeats work the program invalidates mid-cycle, and consumes processor time the application would otherwise use.

open as a page

Promotion out of the young area rises sharply when a service doubles its traffic, though object lifetimes are unchanged — why?

level: seniorimportance: should knowfreq 46%

basics

~20 s

The young area is collected when it fills, so doubling the allocation rate halves the interval between collections. Objects whose lifetime is unchanged now span a larger share of that shorter interval, so more of them are still live when the collector arrives, and more get promoted.

open as a page

An object on the collected heap is referenced only from code outside that heap — what keeps it alive?

level: seniorimportance: should knowfreq 38%

basics

~20 s

A registered handle. Code outside the collected heap holds an opaque handle that the runtime records in a table, and that table is scanned as a root set. A raw address held abroad is invisible to the collector and keeps nothing alive.

open as a page

A batch job's heap is 95% garbage when its trace ends: which finishing move — sweep, sliding compaction or semispace copying — costs least?

level: seniorimportance: should knowfreq 46%

basics

~20 s

Semispace copying, because it touches only the 5% that survives and abandons the rest in one step. Its price is reserved space able to hold every survivor. A sweep is charged for the whole heap; sliding compaction adds address-computing and pointer-rewriting passes on top of marking.

open as a page

A concurrent marker must never free a reachable object; how would you build confidence that its tri-colour invariant actually holds?

level: principalimportance: should knowfreq 30%

basics

~20 s

Make the invariant checkable instead of hoping a test hits the race: scan for black-to-white edges at the end of a cycle, compare against a trace taken with the program stopped, and prove every reference store reaches the barrier.

open as a page

Your latency-critical service keeps losing the race between allocation and its concurrent collector, falling back to a long stop. How do you decide what to change?

level: principalimportance: should knowfreq 36%

basics

~20 s

Treat it as one inequality: allocation rate multiplied by cycle duration must stay under the free space available when a cycle starts. Measure all three at peak, then pick the lever that fixes the ratio at the peak you must survive.

open as a page

How would you decide how much heap headroom each of two hundred stateless replicas of one service gets?

level: principalimportance: should knowfreq 36%

basics

~20 s

Start from the peak live set measured after a collection, choose a multiple of it based on which corner the service can afford to lose, then price the choice: headroom is per replica, so each extra gigabyte is two hundred across the fleet.

open as a page

Your runtime always finishes a trace by sweeping, yet its batch jobs range from 2% to 80% survivors — how would you decide whether to pick the finishing move per cycle?

level: principalimportance: should knowfreq 36%

basics

~20 s

Decide on evidence, not on the range: the copy path only pays where the survivor share is genuinely low, and it must be funded with reserved space in every cycle, including the ones that sweep. Measure the survivor share per cycle, cost both finishes on real traces, and prefer separating workloads over a collector with two paths.

open as a page

When would you let a reference strength cleared only under memory pressure size a cache, instead of an explicit bound?

level: principalimportance: should knowfreq 32%

basics

~20 s

Rarely, and only for values that are cheap to rebuild and genuinely hard to size. The strength delegates eviction to a collector that knows heap pressure but nothing about hit rate, entry cost or fairness, so a fleet service should state a bound instead.

open as a page

Why does a collector that marks while the program keeps running reclaim less than the heap's true garbage at cycle end?

level: middleimportance: nice to knowfreq 28%

basics

~20 s

Because a concurrent trace measures reachability against a moving target. An object that was reachable when the collector saw it, and died a moment later, is already marked and survives the cycle. That unreclaimed dead memory is floating garbage.

open as a page

In three-colour marking (white unreached, grey pending, black scanned), when may a black object safely point at a white one?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

A black-to-white edge is safe when the white target is still reachable from some grey object through a chain of white objects — the weak tri-colour invariant, which requires only that the pending frontier can still walk to the target.

open as a page

Why does a tracing collector's cost rise faster than linearly as the heap approaches its live set?

level: seniorimportance: nice to knowfreq 30%

basics

~20 s

Collector work per allocated byte is the live set divided by the free space, and free space is the quantity being removed. As the denominator shrinks toward zero the ratio grows without bound, so the last gigabyte taken away costs far more than the first.

open as a page

Why do collectors age a survivor through several young collections instead of promoting it the first time it survives?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

One survival is weak evidence of a long life: an object allocated just before a collection survives on timing alone. Requiring several survivals filters those out, so the mature area receives objects that have genuinely proved long-lived rather than unlucky ones.

open as a page

showing 1–30 of 33