How do you compute an application's allocation rate and promotion rate from a HotSpot garbage-collection log, and what do those two numbers tell you?

## Why these two numbers A GC log is mostly a record of two flows: how fast the application creates objects, and how fast objects escape the young generation into the old one. Nearly every GC symptom is a consequence of one of them, so deriving both is the first analytical step after confirming the log is complete. ## Deriving allocation rate Between the end of one collection and the start of the next, no memory is reclaimed — the heap only grows, and it grows exactly by what the application allocated (large objects that bypass eden are the exception, discussed below). So for consecutive collections *n−1* and *n*: ``` allocated = used_before(n) - used_after(n-1) interval = timestamp(n) - timestamp(n-1) rate = allocated / interval // MB/s ``` One pair is noise; average over dozens of collections in a steady-state window, and look at the distribution, not just the mean — a batch job that allocates in bursts has a peak rate the collector must absorb even if its average is modest. What the number means: allocation rate sets young-collection **frequency** for a given eden size. Frequency × pause = the throughput tax of young collection. A very high rate (say, several GB/s) is a signal to look at the code — churn in a hot loop, boxing, defensive copying, oversized log-message formatting — because reducing allocation is usually cheaper than tuning around it. ## Deriving promotion rate Promotion is invisible in the summary line, which reports total heap only. Enable the heap sub-tag: ``` -Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime,level,tags ``` For Serial/Parallel you then get old-generation occupancy before and after each collection; for G1 you get region counts by class (`Eden regions: 24->0(25)`, `Survivor regions: 3->2`, `Old regions: 40->43`, `Humongous regions: 1->1`), and region count × region size gives bytes. ``` promoted(n) = old_used_after(n) - old_used_before(n) promotion rate = sum(promoted) / window duration ``` This number is the one that predicts pain. Everything promoted must eventually be traced by an old-generation cycle and, if it dies there, reclaimed by concurrent marking plus mixed collections, or by a full collection. Promotion rate therefore drives how often concurrent cycles run and how much they have to do, and it is the quantity that turns a healthy young-only rhythm into old-generation churn. ## Interpreting the pair - **High allocation, near-zero promotion** — the ideal generational profile. Objects die young; young collections stay cheap because cost tracks survivors, not garbage. If pauses are still too frequent, the lever is eden size or the collector, not the code. - **High promotion** — objects are surviving. Two very different causes: - *Genuinely long-lived data* — caches, session state, a large steady working set. The old generation must simply be able to hold it; the log will show a high, stable used-after floor. - *Premature promotion* — objects that would have died shortly after, pushed out because survivor space was too small or the tenuring threshold too low, so the collector gave up on ageing them. The tenuring distribution from `-Xlog:gc+age=trace` distinguishes the two: if the distribution shows a lot of bytes at age 1–2 and the desired survivor size exceeds the actual, objects are being flushed out before they get a chance to die. - **Rising used-after floor across the window** — the live set is growing. That is a retention question, pursued with heap-analysis tooling rather than with GC flags. ## Caveats that keep the arithmetic honest - **Humongous / large objects.** G1 allocates objects at least half a region in size directly into old-generation humongous regions, and other collectors can allocate large arrays straight into the old generation. Those bytes appear as promotion without ever having been young, and they distort both numbers. G1's humongous region counts in `gc+heap` output let you see the volume. - **TLAB slack.** Threads allocate in thread-local buffers; unused tail space and retired buffers make the heap-derived figure slightly conservative. It is close enough for tuning decisions. - **Only compare like intervals.** Mixed collections, concurrent-start collections and full collections change the accounting; compute allocation rate across consecutive *young* collections in a steady-state period, excluding startup, warmup and deployment spikes. - **Log-derived rates are averages.** They tell you the shape of the workload; they do not tell you which allocation sites produce it. For that you need allocation profiling, not the GC log. ## What you do with them The pair converts a vague complaint into a quantified statement: "we allocate 1.2 GB/s and promote 40 MB/s; at the current eden size that is a young collection every 250 ms at 12 ms each, and old occupancy grows fast enough to require a concurrent cycle every 90 seconds." That statement is what makes the next decision — resize, retune, change collector, or fix the allocating code — an argument from evidence instead of a guess.