Zero allocation is not the goal

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.