Prerequisites
- Basic familiarity with generational GC concepts (young/old generation, promotion, TLABs).
The useful question
“Does this code allocate?” is too small a question. The useful questions are: how much does it allocate, where, under what load, whether those allocations escape, and whether they disturb the latency distribution.
A service can allocate heavily and still meet its latency objective. Another can allocate almost nothing and still stall on locks, page faults or cache misses. The runtime has no obligation to respect slogans from conference slides.
What I optimise for
- bounded allocation rate under representative load,
- stable object lifetime and promotion behaviour,
- absence of allocation bursts on the hot path,
- predictable p99 and p999 rather than attractive averages.
When zero allocation is justified
It is valuable in tight, repeated, latency-sensitive paths where object churn is measurable and the added complexity remains controlled. It is not a universal architecture principle for every request handler and DTO in the building.
Evidence
Performance Lab does not currently host a benchmarked lab for allocation/GC behaviour, so the guidance above is experience-based rather than measured data on this site. Treat it as a starting hypothesis to verify with your own allocation profiling — async-profiler's allocation mode, JFR's jdk.ObjectAllocationSample event, or GC logs — not as evidence in itself.
Sources and further reading
- HotSpot Virtual Machine Garbage Collection Tuning Guide — Oracle. docs.oracle.com/en/java/javase/21/gctuning
- Java Performance: The Definitive Guide — Scott Oaks, O'Reilly, 2014.