How does a JVM decide the exact age at which a surviving object is promoted into the old generation? Explain both the configured maximum tenuring threshold and the threshold the collector computes at runtime, and how you would observe the actual age distribution.

## The two numbers people confuse There are two distinct thresholds and interview answers routinely merge them: - **The configured maximum** — `-XX:MaxTenuringThreshold`. This is a ceiling, not a target. Its default is 15 on the mainstream generational collectors. The value 15 is not arbitrary: the age is stored in a small field of the object header's mark word (classically 4 bits), so 15 is the largest age representable. Setting it higher is silently clamped. - **The effective (adaptive) threshold** — recomputed at *every* young collection from the actual data. This is the number that decides promotions, and it is frequently far below the configured maximum. ## How the adaptive threshold is computed During evacuation the collector accumulates, per age bucket, how many bytes survived. After copying it walks the histogram from age 1 upward, adding up bytes, and compares the running total against the **desired survivor size**: the survivor space capacity multiplied by `-XX:TargetSurvivorRatio` (default 50%). The first age at which the running total exceeds that budget becomes the effective threshold; objects of that age and above are tenured on the next collection rather than copied to the survivor space. The logic is a capacity argument, not a longevity argument. The collector is not asserting that age-3 objects are long-lived; it is asserting that it does not have room to keep copying them and must move some data out of the way. Keeping survivor occupancy near half of capacity leaves slack for the next cycle's surviving eden data, which is not yet known. ## Reading the distribution The age histogram is printed by `-Xlog:gc+age=trace` on modern JVMs (the pre-JDK-9 spelling was `-XX:+PrintTenuringDistribution`). Each line is one age bucket with the bytes at that age and the running total, followed by the desired survivor size and the threshold chosen. Two patterns matter: - A histogram whose mass sits at ages 1–2 with the threshold pinned at 1, plus a desired-survivor-size line far below the total, means the survivor space is too small for the workload; data is being pushed into the old generation immediately. - A histogram with a long tail that reaches the maximum age means genuinely long-lived data is being copied 15 times before it tenures — pure pause-time overhead, since it was always destined for the old generation. ## Tuning levers and their tradeoffs Survivor capacity is controlled indirectly through `-XX:SurvivorRatio` (eden-to-survivor sizing) on the classic collectors, or emerges from region counts and the ergonomic young-size policy on region-based ones. Adaptive sizing policies may resize survivor spaces between collections on their own, which is why a flag you set may be overridden by ergonomics. Raising the threshold or enlarging survivors keeps medium-lived data out of the old generation, at the cost of longer young pauses (more bytes copied per collection) and less eden for a given young size (more frequent collections). Lowering the threshold hands data to the old generation quickly: young pauses shrink, old-generation pressure grows. There is no universally correct setting — the right answer depends on whether the application's object lifetime distribution has a genuine "medium-lived" hump that survivor spaces can absorb. Setting `MaxTenuringThreshold=0` forces every survivor to be tenured immediately, effectively deleting the survivor filter. It is occasionally used when *all* surviving data is known to be long-lived, but as a general setting it guarantees that short-lived data which merely lost the timing lottery ends up in the old generation. ## The pathological interaction The adaptive threshold and survivor overflow reinforce each other. A burst of allocation produces an unusually large survivor set; the threshold collapses to 1; nearly everything is tenured; the old generation fills with objects that would have died within a second or two. The old generation then needs collecting more often, and old-generation collections are the expensive kind. This is *premature promotion*, and the tell is precisely the collapsed threshold plus large promoted volumes in the age log — not any single flag value. ## Collector-specific notes Region-based collectors keep the same age-and-threshold model but implement survivor spaces as sets of regions rather than fixed contiguous spaces, so the effective survivor capacity moves with each collection's sizing decisions. The generational modes of newer low-pause collectors likewise retain aging, though their promotion policies and the structures recording cross-generational references differ. In all of them the interview-relevant point is unchanged: the configured maximum is an upper bound, and the number that governs behaviour is computed from live data every cycle.