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?

## 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.