A service allocates roughly 1 GB per second of mostly short-lived objects and its young space is 512 MB. How does allocation rate translate into collection frequency, and what levers change that?

## The arithmetic Every byte a thread allocates advances its private buffer pointer, and every buffer refill advances the shared young-space pointer. When the young space cannot serve another buffer, a young collection runs. So: ``` interval between young collections ≈ young space size / allocation rate ``` At 1 GB/s with 512 MB usable young space, that is ~0.5 s, or about two collections per second. This relationship is why allocation rate is the single most predictive number about a JVM workload's collector behaviour. Crucially, frequency and duration have different drivers. Frequency comes from allocation rate versus young size. Duration comes from the live set at collection time, because a copying young collector traces and copies only survivors. That decoupling explains a common observation: a service can allocate enormously and still have millisecond pauses, as long as almost nothing survives. ## Measuring the rate Garbage-collection logs give it directly. Each young collection reports heap occupancy before and after. Occupancy before collection N+1 minus occupancy after collection N is the bytes allocated in between; divide by the wall time between them. Doing this over a representative window gives a steady-state allocation rate. Allocation profiling adds the second half of the picture — which call sites produce those bytes — and the JVM samples it cheaply by hooking the allocation slow path: it records a sample when a thread refills its buffer, and separately when an object is allocated outside a buffer. That is why allocation profiles are sampled per N bytes allocated rather than per object, and why they are nearly free to collect. ## The three levers in order of value **1. Allocate fewer bytes per unit of work.** This improves everything at once: fewer collections, less zeroing, less memory bandwidth, better cache behaviour. Typical wins come from removing per-call temporary objects in hot loops, avoiding autoboxing of primitives in high-throughput paths, reusing buffers where the lifetime is clearly scoped, streaming instead of materializing large intermediate collections, and not building log strings that are then discarded by the level check. **2. Enlarge the young space.** Frequency falls in proportion. There is a second-order benefit: with a longer interval, more objects die naturally before a collection observes them, so both the copied volume and the promotion rate fall. The costs are a bigger memory footprint and, for collectors whose pause scales with survivors, potentially longer individual pauses if the live set grows with the space. **3. Reduce what survives.** Survivors are the expensive part. Objects that outlive a couple of collections get promoted to the old generation, and a high promotion rate is what eventually drives the expensive old-generation work. Caches with unbounded or poorly-tuned lifetimes, per-request state kept alive by asynchronous continuations, and buffers held across an await are common causes of objects surviving just long enough to be promoted. ## What does not help Calling `System.gc()` does not reduce allocation rate; it adds work. Switching collectors changes the shape of pauses, not the volume of bytes your code allocates — a low-pause collector will do the same amount of copying, just concurrently and with more CPU. And object pooling to dodge allocation is usually counterproductive for small short-lived objects, because pooled objects survive by construction, converting cheap young garbage into promoted long-lived data that the old generation must manage. ## Framing an answer A strong answer states the arithmetic, separates frequency from duration, names measurement (logs for rate, sampled allocation profiling for call sites), and orders the fixes: reduce bytes allocated, then size the young space, then attack survivor and promotion volume — with pooling explicitly called out as a last resort rather than a default.