HotSpot's Parallel collector runs with adaptive size policy enabled by default. What exactly is it adapting, in what order of priority, and when would you deliberately disable it with -XX:-UseAdaptiveSizePolicy?

## What ergonomics is The JVM does not want you to hand-tune generation sizes. On startup it picks a collector, a heap size and generation proportions from the machine's CPU count and memory; then, while running, the Parallel collector keeps adjusting those proportions based on what it actually measures. That runtime feedback loop is the **adaptive size policy**, controlled by `-XX:+UseAdaptiveSizePolicy`, which is on by default for this collector. ## The inputs it measures After each collection the policy updates decaying averages of: - **Pause duration** for young collections and for full collections. - **Survival rate** — how much of eden survived, and how much of the survivor space survived again. - **Allocation rate** — how fast the application fills eden, and hence how often collections occur. - **Promotion volume** — how much data moved into the old generation. From these it estimates how a change in size would change the outcome: a larger eden means less frequent but longer young collections; larger survivor spaces mean objects can age longer before promotion, reducing pressure on the old generation; a larger old generation means less frequent full collections but a longer compaction when one happens. ## The knobs it turns - **Eden size** — the main lever on young collection frequency. - **Survivor space size**, which is really the survivor ratio, i.e. how eden and the two survivor spaces divide the young generation. - **Young/old split**, and the total heap between `-Xms` and `-Xmx`. - **Tenuring threshold** — how many young collections an object must survive before promotion, bounded by `-XX:MaxTenuringThreshold`. If survivor spaces overflow, the policy lowers the threshold, promoting objects sooner. ## The three goals, in strict priority 1. **Pause-time goal** — `-XX:MaxGCPauseMillis=N`. This is not a guarantee, it is a target. If measured pauses exceed it, the policy shrinks the generation responsible: less data per collection means shorter stops. Note the feedback trap — smaller generations means *more* collections, so satisfying an aggressive pause goal directly costs throughput. 2. **Throughput goal** — `-XX:GCTimeRatio=N`, targeting a GC overhead of `1/(1+N)`. The default 99 asks for 1%. If GC overhead exceeds the target and the pause goal is being met, the policy grows generations, trading longer but rarer collections for less total overhead. 3. **Footprint** — only when both goals are comfortably met does the policy shrink the heap to give memory back. The priority ordering is the single most important thing to know: a pause goal always outranks the throughput goal. Setting `-XX:MaxGCPauseMillis=50` on a throughput collector is a common self-inflicted wound — it can drive the heap small enough that the application spends far more total time collecting than it would with no pause goal at all. ## Interactions and surprises - **Explicit ratios get overridden.** With the adaptive policy on, `-XX:SurvivorRatio` and similar explicit sizing flags are recomputed by the policy. Candidates who set them and then see different values in the log are usually hitting exactly this. - **Survivor collapse.** A well-known pathology: under certain workloads the policy shrinks survivor spaces toward nothing. Every young collection then promotes almost everything, the old generation fills quickly, and full collection frequency spikes. The symptom in the log is a young collection whose "after" occupancy is near zero while old-generation occupancy climbs in steps of the same size. - **Oscillation.** Because the policy reacts to a changing workload, a service with distinct phases (warm-up, batch window, idle) can spend its time chasing a moving target, with generation sizes swinging. - **Non-reproducibility.** Two runs of the same benchmark on the same machine can size differently depending on timing, which makes measurement noisy. ## When to disable it Set `-XX:-UseAdaptiveSizePolicy` and pin sizes explicitly when: - You are **benchmarking or capacity testing** and need runs to be comparable. - You have **already measured** the steady-state profile of a stable workload and can set eden, survivor and old sizes better than a general heuristic can infer them. - You are **diagnosing or fixing survivor collapse** or premature promotion and want the survivor ratio and tenuring threshold to stay where you put them. - The workload is **uniform and long-running**, so adaptation buys nothing and only adds variance. Keep it on for general-purpose services with unknown or shifting workloads — a heuristic that adapts usually beats a fixed guess. ## How to see what it is doing Unified logging exposes the ergonomics decisions: `-Xlog:gc+ergo*=debug` prints the goal being pursued and the resize decisions, alongside `-Xlog:gc+heap=debug` for the resulting sizes. Always confirm from the log rather than assuming your flags took effect. ## Interview framing "It resizes the generations and the tenuring threshold from measured statistics, pursuing pause goal, then throughput goal, then footprint — in that order. I leave it on for general services, and turn it off for benchmarks or when I've measured a stable profile and want deterministic sizing, especially if the survivor spaces are being squeezed into premature promotion."