Trace what happens to a newly allocated Java object that stays reachable across several young-generation collections: where does it physically live at each step, what copies it, and what eventually moves it into the old generation?
answer
- eden → survivor (copy) → survivor → old
- age bits in the mark word, max 15
- copy cost ∝ survivors, not garbage
- empty *to* survivor always reserved
- overflow or huge object ⇒ straight to old
basics
~20 sIt is allocated in eden. Each young collection copies the still-live object into the currently empty survivor space and increments its age. After surviving enough collections (age reaching the tenuring threshold) it is copied into the old generation instead — that copy is called promotion.
solid answer
~50 sA new object is allocated in eden (normally in the thread's own allocation buffer). When eden fills, a young collection runs: the collector finds objects reachable from the roots plus from old-to-young references, and **copies** them into the empty survivor space (the "to" space). Eden and the previously used survivor space are then declared empty in one step — nothing is touched for dead objects, which is why the collection costs time proportional to what *survived*, not to what was allocated. Each copy increments an age counter kept in the object's header. On each subsequent young collection the object is copied again, ping-ponging between the two survivor spaces, until its age reaches the tenuring threshold; at that point it is copied into the old generation instead — promotion. An object can also skip the ladder: if the survivor space cannot hold everything that survived, the overflow goes straight to the old generation, and very large objects may be allocated there directly.
go deeper
Be able to name the sequence out loud — eden, survivor copy, age increments, promotion to old — and state that only live objects are copied.
Add the mechanics: the age counter lives in the object header, the two survivor spaces alternate roles, and overflow or the adaptive threshold can promote earlier than the configured maximum.
Connect the path to observable symptoms: survivors overflowing produce old-generation growth without a growing live set, and repeated copying of medium-lived data shows up as young-pause duration scaling with survivor volume.
Frame it as a cost model — young pauses cost O(survivors), old-generation collections cost far more, and every design or sizing decision is about keeping data from crossing that boundary before it has earned it.
## The starting point: eden The young generation of a HotSpot heap is split into one **eden** space and two **survivor** spaces (conventionally called *from* and *to*). Almost every object begins life in eden. Allocation there is a pointer bump inside a thread-local buffer, so it is extremely cheap; the cost of the generational design is paid later, at collection time. ## What a young (minor) collection actually does When eden cannot satisfy an allocation, a young collection is triggered. It is a **copying** (evacuating) collector, not a mark-and-sweep of the whole heap. The steps are: 1. Enumerate the roots — thread stacks, static fields, JNI handles and so on — **plus** the recorded old-to-young references (see the remembered-set mechanism, which is what lets this step skip the old generation entirely). 2. Trace only into the young generation and **copy** every live object found into the currently empty survivor space, fixing up references to the new addresses. 3. Declare eden and the survivor space that was in use to be entirely free. The crucial property: dead objects are never visited, never touched, never "freed" individually. Reclaiming them costs nothing. The work is proportional to the volume of data that *survived* the collection. That is exactly why the design pays off when most objects die young. After the collection the two survivor spaces swap roles: the one just filled becomes *from* for the next cycle, and the emptied one becomes *to*. At all times one survivor space is empty, which is the space reserved for the next copy. ## Aging Every time an object is copied during a young collection its **age** is incremented. HotSpot stores this age in a few bits of the object header's mark word — historically 4 bits, which is why the maximum age is 15. An object with age 3 has survived three young collections. When the age reaches the **tenuring threshold**, the collector copies the object into the **old generation** instead of into a survivor space. That transfer is called *promotion* or *tenuring*. Once promoted, the object is no longer visited by young collections at all; it will only be reclaimed by an old-generation or full collection. ## Ways to skip the ladder The eden → survivor → survivor → old path is the normal case, not the only one: - **Survivor overflow.** The *to* survivor space is a fixed, comparatively small region. If more data survives than fits, the excess is promoted directly to the old generation regardless of age. This is the main mechanism behind *premature promotion*. - **Threshold collapse.** Collectors compute an adaptive threshold from the actual age distribution: if the survivors already overflow the target occupancy at a low age, the effective threshold drops, and objects tenure after one or two collections. - **Large objects.** Some collectors allocate objects above a size threshold straight into the old generation, because copying them repeatedly would cost more than it saves. In region-based collectors, objects that span half a region or more are *humongous* and are allocated directly into old-generation regions. - **Promotion failure.** If the old generation cannot accept the promotions, the collection fails and escalates — typically to a full, compacting collection, which is the expensive event the whole design exists to avoid. ## Why the ladder exists at all Why not promote survivors immediately, and drop the survivor spaces? Because a single young collection is a very poor test of longevity. An object that happens to be alive at the instant a collection fires may still be a short-lived temporary — it merely lost the timing lottery. The survivor spaces impose a *repeated* test: only data that stays reachable across several collections is judged genuinely long-lived and moved to the region that is expensive to collect. The survivor spaces are, in effect, a filter that keeps garbage out of the old generation. ## The observable consequences This mechanism explains most everyday GC behaviour. Allocating enormous numbers of short-lived objects is cheap, because they simply never get copied. Holding a moderate amount of medium-lived data is expensive, because it is copied repeatedly between survivor spaces before being promoted. And a burst of allocation that outruns the survivor space quietly pushes short-lived garbage into the old generation, where it can only be cleaned up by a much more expensive collection.
- Why does a young collection copy live objects rather than free the dead ones in place?Because in a young generation the overwhelming majority of objects are dead, so the live set is tiny. A copying collector touches only the live data and then frees the entire region in one operation, making its cost proportional to survivors rather than to heap size. It also compacts as a side effect, so allocation afterwards is a cheap pointer bump with no fragmentation.
- Why are there two survivor spaces instead of one?A copying collector needs an empty destination to evacuate into, so one survivor space must always be free at the start of a collection. The collector copies eden's survivors plus the occupants of the in-use survivor space into the empty one, then swaps their roles. With a single survivor space there would be nowhere to compact the previous survivors into.
Survivor spaces are a probation period. One young collection is like passing a single day on the job — not proof of anything. Only after repeatedly showing up does an object get the permanent contract (promotion) into the region that is costly to clean.
saying these in an interview costs you the question
- Saying objects are 'moved from eden to survivor when eden is full' as if eden fullness alone moves data — it is the collection that copies, and only live objects move.
- Claiming dead objects are individually freed or their memory zeroed one by one during a young collection.
- Believing every survivor is promoted after exactly one collection, ignoring survivor-space aging.
- Assuming the tenuring threshold is a fixed constant that the JVM never varies at runtime.
- Thinking large objects always start in eden.