Allocation Profiling¶
"Most 'GC problems' are allocation problems in disguise — the GC ran a lot because there was a lot to collect."
Allocation profiling attributes where allocations happen, not what stays alive. In GC'd languages this is usually a better optimisation target than heap usage, because reducing allocation rate reduces both GC pressure and per-call cost.
Scope¶
- Go
pprof -alloc_spaceand-alloc_objects— the two questions are different - Java JFR allocation events, async-profiler
--alloc - Python
tracemalloc,mem_top - .NET ETW allocation events
- The escape-analysis connection — what would have stayed on the stack but didn't
- Reading: per-call-site allocation totals vs counts; "many small" vs "few large"
- Common culprits: hidden boxing, string concatenation, defensive copies, intermediate slices
Related¶
- Memory Profiling — what's retained (different question, same tool sometimes).
- Memory Optimization — reducing rate at the source.
- Language Internals → Escape Analysis — why some allocations could have stayed on the stack.
- Language Internals → Tracing GC — why allocation rate matters for pause times.
Status¶
⏳ Per-tier files (junior / middle / senior / professional / interview) pending.