@wazir-dev/cli 1.0.0

package/expertise/performance/foundations/memory-management.md

@@ -0,0 +1,964 @@
+# Memory Management Performance Expertise Module
+
+> **Scope**: Hardware memory hierarchy, garbage collection strategies and tuning,
+> memory leak detection, cache-friendly data structures, allocation patterns,
+> and diagnostic workflows.
+>
+> **Audience**: Performance engineers, backend developers, and SREs responsible
+> for latency-sensitive or memory-constrained services.
+
+---
+
+## 1. Memory Hierarchy: The Numbers That Matter
+
+Every performance decision starts with understanding the cost of reaching data.
+Modern processors rely on a multi-level cache hierarchy; a miss at any level
+forces the CPU to wait for the next, slower tier.
+
+| Level | Typical Size | Latency (cycles) | Latency (approx.) | Bandwidth |
+|-------|-------------|-------------------|--------------------|-----------|
+| L1 Cache | 32-64 KB per core (up to 192 KB on Apple M-series) | 4 cycles | ~1 ns | ~1 TB/s |
+| L2 Cache | 256 KB - 1 MB per core | 12 cycles | ~3-4 ns | ~500 GB/s |
+| L3 Cache | 8-64 MB shared | 30-40 cycles | ~10-12 ns | ~200 GB/s |
+| Main RAM (DDR5) | 16-512 GB | 200+ cycles | ~60-100 ns | ~50-100 GB/s |
+| NVMe SSD | TB-scale | - | ~10-100 us | ~7 GB/s |
+| Network (same DC) | - | - | ~500 us | ~12.5 GB/s (100GbE) |
+
+Source: CPU cache data from [CPU cache - Wikipedia](https://en.wikipedia.org/wiki/CPU_cache);
+cache line measurements from [Daniel Lemire's blog](https://lemire.me/blog/2023/12/12/measuring-the-size-of-the-cache-line-empirically/);
+modern processor specs from [StoredBits](https://storedbits.com/cpu-cache-l1-l2-l3/).
+
+### 1.1 Cache Line Fundamentals
+
+- Standard cache line size: **64 bytes** on x86/AMD64 processors.
+- Apple ARM64 (M1/M2/M3/M4): **128-byte** cache lines.
+- IBM POWER7-9: **128-byte** cache lines; IBM s390x: **256-byte** cache lines.
+- All memory transfers between cache levels happen in full cache-line units.
+  Accessing a single byte loads the entire 64-byte (or 128-byte) line.
+
+**Practical implication**: If a struct is 72 bytes on x86, it spans two cache
+lines. Accessing any field may trigger two cache-line fetches. Padding or
+reordering fields to fit within 64 bytes eliminates this penalty.
+
+### 1.2 TLB and Page Size
+
+Translation Lookaside Buffer (TLB) misses add 7-30 ns per access. Standard 4 KB
+pages mean a 256 MB working set requires 65,536 TLB entries. Using 2 MB huge
+pages reduces that to 128 entries, dramatically reducing TLB misses. Linux
+Transparent Huge Pages (THP) can automate this but may cause latency spikes from
+compaction; explicit `madvise(MADV_HUGEPAGE)` gives finer control.
+
+---
+
+## 2. Garbage Collection Strategies
+
+### 2.1 Core GC Approaches
+
+| Strategy | Mechanism | Pause Characteristic | Throughput Overhead |
+|----------|-----------|---------------------|---------------------|
+| **Reference Counting** | Decrement on release; free at zero | No GC pauses; deallocation inline | Low, but cycles require backup tracing |
+| **Mark-and-Sweep** | Trace from roots; sweep unmarked | Stop-the-world; proportional to heap | Low overhead between collections |
+| **Mark-and-Compact** | Trace, then relocate live objects | Longer pauses; eliminates fragmentation | Moderate; compaction is expensive |
+| **Copying (Semi-space)** | Copy live objects to new space | Fast for young gen; half memory wasted | Very low for short-lived objects |
+| **Generational** | Separate young/old spaces | Frequent minor pauses; rare major | Best overall throughput for typical workloads |
+| **Concurrent** | GC runs alongside application | Sub-ms pauses; requires barriers | 5-15% CPU overhead for GC threads |
+| **Incremental** | GC work interleaved with application | Bounded pauses per increment | Moderate; write barriers add cost |
+
+### 2.2 Generational GC Hypothesis
+
+Most objects die young. Empirical measurements across languages consistently show
+that 80-98% of objects become unreachable within their first GC cycle. Generational
+collectors exploit this by:
+
+1. Allocating into a small **nursery** (young generation).
+2. Running frequent, fast minor collections on the nursery.
+3. **Promoting** survivors to older generations collected less frequently.
+4. Running major (full) collections only when older generations fill up.
+
+---
+
+## 3. GC Tuning by Runtime
+
+### 3.1 JVM (Java / Kotlin / Scala)
+
+The JVM offers the most mature GC ecosystem. Choose based on your primary
+constraint (pick two of three: latency, throughput, footprint).
+
+#### Collector Comparison (Java 21+)
+
+| Collector | Typical Pause | Max Heap | CPU Overhead | Best For |
+|-----------|---------------|----------|--------------|----------|
+| **G1GC** (default) | 10-200 ms | Multi-TB | Baseline | General purpose, balanced |
+| **ZGC** | 0.1-1 ms | 16 TB | +5-10% CPU | Ultra-low latency |
+| **Shenandoah** | 1-10 ms | TB-scale | +5-15% CPU | Low latency, Red Hat ecosystem |
+| **Parallel GC** | 50-500 ms | Large heaps | Lowest CPU | Batch processing, throughput |
+| **Serial GC** | Varies | Small heaps | Minimal threads | Containers with 1 vCPU |
+
+Sources: [Java Code Geeks - G1 vs ZGC vs Shenandoah](https://www.javacodegeeks.com/2025/08/java-gc-performance-g1-vs-zgc-vs-shenandoah.html);
+[Gunnar Morling - Lower Java Tail Latencies With ZGC](https://www.morling.dev/blog/lower-java-tail-latencies-with-zgc/);
+[Datadog - Deep dive into Java GC](https://www.datadoghq.com/blog/understanding-java-gc/).
+
+**ZGC benchmark highlight**: In production testing, ZGC achieved pause times
+consistently under 0.5 ms regardless of heap size (tested up to 128 GB), with
+occasional spikes to ~1 ms under extreme allocation pressure. G1GC on the same
+workload showed pauses exceeding 20 ms.
+
+#### Key JVM GC Flags
+
+```bash
+# G1GC with 200ms pause target
+-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xmx8g -Xms8g
+
+# ZGC for sub-millisecond pauses (Java 21+)
+-XX:+UseZGC -XX:+ZGenerational -Xmx16g -Xms16g
+
+# Shenandoah (OpenJDK / Red Hat builds)
+-XX:+UseShenandoahGC -Xmx8g -Xms8g
+
+# Diagnostic flags (always enable in production)
+-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=100m
+-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps/
+```
+
+#### JVM Tuning Checklist
+
+1. **Set -Xms equal to -Xmx** to avoid heap resizing pauses.
+2. **Size young generation** via `-XX:NewRatio` or `-XX:NewSize`. More young-gen
+   space reduces promotion rate and major GC frequency.
+3. **Monitor promotion rate**: If objects promote too quickly, young gen is too
+   small or objects live too long.
+4. **GC log analysis**: Use GCEasy or GCViewer to identify pause time
+   distributions, allocation rates, and promotion rates.
+5. **Avoid finalizers**: They add a full GC cycle delay to reclamation and
+   create GC pressure. Use `Cleaner` or try-with-resources instead.
+
+Source: [LinkedIn Engineering - GC Optimization](https://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications);
+[Atlassian - GC Tuning Guide](https://confluence.atlassian.com/enterprise/garbage-collection-gc-tuning-guide-461504616.html).
+
+### 3.2 V8 / Node.js
+
+V8's **Orinoco** garbage collector uses a generational approach with parallel,
+concurrent, and incremental techniques to minimize pauses.
+
+#### Memory Spaces
+
+| Space | Purpose | Default Size |
+|-------|---------|-------------|
+| **New Space (Young Gen)** | Short-lived objects; semi-space copying | 16 MB (2 x 8 MB semi-spaces) |
+| **Old Space** | Promoted long-lived objects; mark-sweep-compact | Up to ~1.5 GB (64-bit default) |
+| **Large Object Space** | Objects > 512 KB; never moved | Part of old space budget |
+| **Code Space** | JIT-compiled machine code | Variable |
+
+#### Key V8/Node.js Tuning Flags
+
+```bash
+# Increase heap for memory-intensive apps (in MB)
+node --max-old-space-size=4096 app.js
+
+# Increase semi-space for high allocation rates (in MB)
+# Measured 18% throughput improvement in one benchmark
+node --max-semi-space-size=128 app.js
+
+# Enable GC tracing for diagnostics
+node --trace-gc app.js
+
+# Expose GC for manual triggering (use sparingly)
+node --expose-gc app.js
+```
+
+**Semi-space tuning impact**: Increasing `--max-semi-space-size` from default
+(8 MB) to 128 MB reduced Old Space promotion rates significantly, yielding an
+**18% throughput improvement** in high-allocation workloads by reducing the
+frequency of expensive Old Space GC cycles.
+
+Source: [Platformatic - V8 GC Optimization](https://blog.platformatic.dev/optimizing-nodejs-performance-v8-memory-management-and-gc-tuning);
+[V8 Blog - Trash Talk: Orinoco GC](https://v8.dev/blog/trash-talk);
+[Node.js issue #42511](https://github.com/nodejs/node/issues/42511).
+
+### 3.3 Go
+
+Go uses a **concurrent, tri-color mark-and-sweep** collector without generational
+separation. GC pauses are typically under 1 ms, achieved through concurrent
+marking and sweeping with write barriers.
+
+#### GOGC and GOMEMLIMIT
+
+| Variable | Default | Effect |
+|----------|---------|--------|
+| `GOGC` | 100 | Triggers GC when new allocations reach this % of live heap. GOGC=200 means collect at 2x live heap. |
+| `GOMEMLIMIT` | None | Soft cap on total Go runtime memory. GC becomes aggressive near this limit. |
+
+**Trade-offs**:
+- **GOGC=50**: More frequent GC, lower peak memory, higher CPU overhead, shorter pauses.
+- **GOGC=200**: Less frequent GC, higher peak memory, lower CPU overhead.
+- **GOMEMLIMIT**: Prevents OOM in containers but risks "death spiral" if live heap
+  approaches the limit (GC runs continuously, consuming all CPU).
+
+**Production case study**: An ad platform handling tens of thousands of requests
+per second saw P99 latency spike to 50 ms with default GOGC=100. Tuning to
+GOGC=50 brought P99 under 20 ms. Uber implemented dynamic GC tuning across Go
+services and saved tens of thousands of CPU cores.
+
+Source: [Go GC Guide](https://go.dev/doc/gc-guide);
+[Go Performance Guide - GC](https://goperf.dev/01-common-patterns/gc/);
+[Go issue #68346](https://github.com/golang/go/issues/68346).
+
+#### Go Memory Optimization Patterns
+
+```go
+// Pre-allocate slices to avoid repeated growth
+data := make([]Record, 0, expectedSize)
+
+// Use sync.Pool for frequently allocated/deallocated objects
+var bufPool = sync.Pool{
+    New: func() interface{} {
+        return make([]byte, 0, 4096)
+    },
+}
+
+// Reduce allocations: pass pointers, reuse buffers
+buf := bufPool.Get().([]byte)
+defer bufPool.Put(buf[:0])
+```
+
+### 3.4 Python (CPython)
+
+CPython uses **reference counting** as its primary mechanism, supplemented by a
+**cyclic garbage collector** for reference cycles.
+
+#### Generation Thresholds
+
+| Generation | Default Threshold | Collected When |
+|------------|-------------------|----------------|
+| Gen 0 | 700 allocations | allocs - deallocs > 700 |
+| Gen 1 | 10 Gen-0 collections | Every 10th Gen-0 run |
+| Gen 2 | 10 Gen-1 collections | Every 10th Gen-1 run |
+
+#### Tuning Options
+
+```python
+import gc
+
+# View current thresholds
+print(gc.get_threshold())  # (700, 10, 10)
+
+# Adjust for workload with many long-lived objects
+gc.set_threshold(1000, 15, 15)
+
+# Disable GC for performance-critical section
+gc.disable()
+# ... hot loop with many temporary objects ...
+gc.collect()  # Manual sweep
+gc.enable()
+
+# Freeze long-lived objects to skip them in future scans (Python 3.7+)
+gc.freeze()  # All currently tracked objects become exempt
+```
+
+**gc.freeze() use case**: In Django/Flask applications with large in-memory
+caches, calling `gc.freeze()` after initialization can reduce GC scan time
+by 30-50% because the collector skips frozen objects entirely.
+
+Source: [Python gc module docs](https://docs.python.org/3/library/gc.html);
+[Artem Golubin - Python GC internals](https://rushter.com/blog/python-garbage-collector/).
+
+---
+
+## 4. Memory Leak Patterns and Detection
+
+### 4.1 Common Leak Patterns by Language
+
+| Pattern | Languages | Example | Impact |
+|---------|-----------|---------|--------|
+| **Forgotten event listeners** | JS, Java, C# | `emitter.on('data', fn)` never removed | Objects retained by listener closure |
+| **Unbounded caches** | All | Map grows indefinitely without eviction | Heap grows linearly with requests |
+| **Closures capturing scope** | JS, Python | Lambda captures parent scope variables | Entire scope tree retained |
+| **Static/global references** | Java, C#, Go | Static `List<>` accumulates entries | Never eligible for GC |
+| **Circular references** | Python, ObjC | A -> B -> A with no weak refs | CPython: only cyclic GC can collect |
+| **Unreleased native resources** | Java, .NET | DB connections, file handles not closed | OS resource exhaustion + heap retention |
+| **Detached DOM nodes** | JavaScript | DOM removed but JS reference remains | Entire subtree retained in memory |
+| **Goroutine leaks** | Go | Goroutine blocks on channel forever | 2-8 KB stack per goroutine, unbounded |
+
+### 4.2 Detection Techniques
+
+#### Heap Snapshot Comparison (The Gold Standard)
+
+The most reliable technique for finding leaks is comparing heap snapshots
+taken at different points in time.
+
+**Process**:
+1. Take **Snapshot A** (baseline, after warmup).
+2. Execute the suspected leaking operation N times.
+3. Force a GC cycle.
+4. Take **Snapshot B**.
+5. Compare: objects with **increasing count or retained size** between A and B
+   are strong leak candidates.
+
+**Key metrics**:
+- **Shallow size**: Memory consumed by the object itself.
+- **Retained size**: Memory freed if this object were garbage collected
+  (includes all exclusively-referenced children). This is the critical metric
+  for leak analysis.
+
+Source: [Chrome DevTools - Heap Snapshots](https://developer.chrome.com/docs/devtools/memory-problems/heap-snapshots);
+[Halodoc - Fix Node.js Memory Leaks](https://blogs.halodoc.io/fix-node-js-memory-leaks/).
+
+#### Tools by Runtime
+
+| Runtime | Tool | Capability |
+|---------|------|-----------|
+| **JVM** | VisualVM, Eclipse MAT, async-profiler | Heap dumps, allocation tracking, flame graphs |
+| **JVM** | Java Flight Recorder (JFR) | Low-overhead production profiling (~2% CPU) |
+| **JVM** | jcmd + jmap | Command-line heap dumps and histograms |
+| **Node.js** | Chrome DevTools Memory tab | Heap snapshots, allocation timeline |
+| **Node.js** | `--inspect` + `v8.writeHeapSnapshot()` | Production-safe snapshot capture |
+| **Python** | tracemalloc | Track allocation origin with file:line |
+| **Python** | objgraph, Scalene | Reference graph visualization, leak detection |
+| **Go** | pprof (`/debug/pprof/heap`) | Live heap profile with allocation stacks |
+| **Go** | runtime.ReadMemStats | Programmatic heap/GC metrics |
+| **C/C++** | Valgrind (Memcheck) | Definite/possible leak detection at exit |
+| **C/C++** | AddressSanitizer (ASan) | Compile-time instrumentation; ~2x slowdown |
+| **.NET** | dotMemory, dotnet-dump | Heap snapshots, retention paths |
+
+#### Production Monitoring Signals
+
+Monitor these metrics continuously; trend-based alerting catches leaks before OOM:
+
+- **RSS (Resident Set Size)**: Monotonically increasing RSS is the first signal.
+- **Heap used after GC**: Plot heap size at each GC boundary. Upward trend = leak.
+- **GC frequency**: Increasing GC frequency with stable allocation rate = growing
+  live set.
+- **GC pause duration**: Increasing major GC pauses indicate a growing old
+  generation.
+
+Source: [Microsoft Azure - RESIN memory leak detection](https://azure.microsoft.com/en-us/blog/advancing-memory-leak-detection-with-aiops-introducing-resin/);
+[Browserless - Memory Leak Guide](https://www.browserless.io/blog/memory-leak-how-to-find-fix-prevent-them).
+
+---
+
+## 5. Cache-Friendly Data Structures
+
+### 5.1 Arrays vs. Linked Lists
+
+Contiguous memory layout is the single most impactful factor for iteration
+performance on modern hardware.
+
+| Operation | Array/Vector | Linked List | Why |
+|-----------|-------------|-------------|-----|
+| Sequential iteration | ~1 ns/element (L1 hits) | ~5-60 ns/element (cache misses) | Spatial locality; prefetcher works |
+| Random access | O(1), ~1-4 ns | O(n), pointer chasing | Each node may be a cache miss |
+| Insertion at front | O(n) memmove | O(1) | But memmove is hardware-optimized |
+| Insertion at middle | O(n) | O(1) if at cursor | Array still often wins due to cache |
+
+**Benchmark evidence**: Linked list traversal triggers frequent cache and TLB
+misses because nodes are scattered across memory. The CPU prefetcher cannot
+predict the next address. Even for insertions, arrays outperform linked lists
+for collections under ~10,000 elements because the cost of cache misses
+dominates pointer manipulation savings.
+
+**When linked lists may win**: When elements exceed ~256 bytes and the workload
+is insertion-heavy, avoiding element copies can outweigh cache-miss penalties.
+
+Source: [DZone - Array vs Linked List Performance](https://dzone.com/articles/performance-of-array-vs-linked-list-on-modern-comp);
+[arXiv - RIP Linked List](https://arxiv.org/html/2306.06942v2);
+[AlgoCademy - Cache-Friendly Data Structures](https://algocademy.com/blog/cache-friendly-algorithms-and-data-structures-optimizing-performance-through-efficient-memory-access/).
+
+### 5.2 Struct of Arrays (SoA) vs. Array of Structs (AoS)
+
+This is one of the highest-impact transformations for data-intensive workloads.
+
+**Array of Structs (AoS)** -- the natural OOP layout:
+```
+[{x, y, z, color, normal}, {x, y, z, color, normal}, ...]
+```
+
+**Struct of Arrays (SoA)** -- the data-oriented layout:
+```
+{xs: [x, x, ...], ys: [y, y, ...], zs: [z, z, ...], ...}
+```
+
+| Aspect | AoS | SoA |
+|--------|-----|-----|
+| Cache utilization when accessing 1 field | Low: loads unused fields into cache | High: only needed data in cache |
+| SIMD vectorization | Hard: mixed types in registers | Easy: homogeneous data, direct SIMD load |
+| Code readability | Natural, object-oriented | Less intuitive, requires discipline |
+| Random single-object access | Good: entire object in 1-2 cache lines | Poor: fields scattered across arrays |
+| Measured speedup (field iteration) | Baseline | **40-60% faster**; up to **40x** in extreme cases |
+
+**Hybrid: AoSoA (Array of Structs of Arrays)**: Interleave data in blocks
+matching the SIMD vector width (e.g., 8 or 16 elements). Achieves SoA's
+throughput while maintaining better cache locality for multi-field access.
+
+Source: [Wikipedia - AoS and SoA](https://en.wikipedia.org/wiki/AoS_and_SoA);
+[Medium - SoA vs AoS Deep Dive](https://medium.com/@azad217/structure-of-arrays-soa-vs-array-of-structures-aos-in-c-a-deep-dive-into-cache-optimized-13847588232e);
+[Serge Skoredin - Cache-Friendly Go](https://skoredin.pro/blog/golang/cpu-cache-friendly-go).
+
+### 5.3 Cache-Line Alignment Techniques
+
+```c
+// Align struct to cache line to prevent false sharing
+struct __attribute__((aligned(64))) Counter {
+    uint64_t value;
+    char padding[56]; // Fill to 64 bytes
+};
+
+// In Go: pad structs to avoid false sharing between goroutines
+type PaddedCounter struct {
+    Value uint64
+    _     [56]byte // Pad to 64-byte cache line
+}
+```
+
+**False sharing** occurs when two threads write to different fields that share
+the same cache line, causing the line to bounce between CPU cores. Padding
+eliminates this; measured impact is often **2-10x throughput improvement** for
+contended counters.
+
+---
+
+## 6. Object Pooling and Arena Allocation
+
+### 6.1 Object Pooling
+
+Object pooling pre-creates and reuses expensive objects rather than allocating
+and deallocating them repeatedly.
+
+#### When Pooling Helps
+
+| Object Type | Creation Cost | Pool Benefit |
+|-------------|--------------|--------------|
+| Database connections | 5-50 ms (TCP + auth + TLS) | Massive: amortize handshake |
+| Thread / goroutine | 1-8 KB stack allocation | Moderate: reduces GC pressure |
+| Large byte buffers | Allocation + zeroing | Moderate: avoids GC churn |
+| Small value objects | ~10 ns allocation | **Negative**: pool overhead > allocation cost |
+
+**Anti-pattern warning**: Do not pool cheap objects. In languages with efficient
+allocators (Go, Java, modern C++), the overhead of synchronized pool access
+(lock contention, cache invalidation) can exceed the cost of simple allocation.
+Benchmark before adopting pooling.
+
+Source: [Webtide - Object Pooling Benchmarks](https://webtide.com/object-pooling-benchmarks-and-another-way/);
+[Medium - Benchmarking Object Pools](https://medium.com/@chrishantha/benchmarking-object-pools-6df007a31ada).
+
+#### Pool Implementation Patterns
+
+```go
+// Go: sync.Pool -- GC-aware, automatically shrinks
+var bufPool = sync.Pool{
+    New: func() interface{} { return new(bytes.Buffer) },
+}
+
+func handleRequest(data []byte) {
+    buf := bufPool.Get().(*bytes.Buffer)
+    buf.Reset()
+    defer bufPool.Put(buf)
+    // Use buf...
+}
+```
+
+```java
+// Java: Apache Commons Pool2 with bounded size
+GenericObjectPool<Connection> pool = new GenericObjectPool<>(factory);
+pool.setMaxTotal(50);
+pool.setMaxIdle(10);
+pool.setMinIdle(5);
+pool.setTestOnBorrow(true);
+```
+
+### 6.2 Arena (Region-Based) Allocation
+
+An arena allocates from a large contiguous block by advancing a pointer.
+Deallocation happens in bulk when the entire arena is freed.
+
+| Metric | malloc/free | Arena Allocator |
+|--------|-------------|-----------------|
+| Allocation time | 40-75 ns | 8-12 ns |
+| Deallocation time | 250-1000 ns per free() | ~0 ns (bulk free) |
+| Fragmentation | Grows over time | Zero (contiguous block) |
+| Memory overhead | Per-allocation bookkeeping | Single pointer + block |
+
+**Benchmark**: On Intel i7-10750H, arena allocation measured at **9.2 ns** vs
+system allocator (Box/malloc) at **71-74 ns** -- a **7-8x speedup**.
+Pool allocators measured at **8.9 ns**, and shared arenas at **12.2 ns**.
+
+Source: [Medium - Arena Allocators 50-100x Performance](https://medium.com/@ramogh2404/arena-and-memory-pool-allocators-the-50-100x-performance-secret-behind-game-engines-and-browsers-1e491cb40b49);
+[Ryan Fleury - Untangling Lifetimes](https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator);
+[OneUpTime - Arena Allocators in Rust](https://oneuptime.com/blog/post/2026-01-25-optimize-memory-arena-allocators-rust/view).
+
+#### Ideal Use Cases for Arenas
+
+- **Per-request processing**: Allocate all request objects from an arena; free
+  the entire arena when the request completes.
+- **Compiler/parser phases**: Parse tree nodes share a lifetime; arena-allocate
+  and bulk-free after the phase.
+- **Game frame allocation**: Per-frame scratch memory reset each tick.
+- **Protobuf/serialization**: Google's Protobuf Arena API allocates message
+  trees from a single arena, reducing GC pressure by 60-80% in benchmarks.
+
+---
+
+## 7. Memory Fragmentation and Compaction
+
+### 7.1 Types of Fragmentation
+
+- **External fragmentation**: Free memory exists but is scattered in small,
+  non-contiguous blocks. A 100 MB allocation fails even though 200 MB is free
+  in total.
+- **Internal fragmentation**: Allocated blocks are larger than needed due to
+  alignment or minimum allocation sizes. A 17-byte request gets a 32-byte slot.
+
+### 7.2 Fragmentation in Practice
+
+**jemalloc** (used by Redis, Rust, Firefox) reports fragmentation via
+`stats.allocated` vs `stats.resident`. A ratio above 1.5 indicates significant
+fragmentation. Redis documentation recommends restarting instances when
+fragmentation ratio exceeds 1.5.
+
+**Linux kernel**: Memory fragmentation triggers **direct compaction** when the
+kernel cannot find contiguous pages for allocation. This blocks the requesting
+process and adds 1-100 ms of latency. PingCAP documented this as a root cause
+of TiDB tail-latency spikes in production.
+
+Source: [PingCAP - Linux vs Memory Fragmentation](https://www.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-1/);
+[Oracle Diagnostician - Memory Fragmentation](https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/).
+
+### 7.3 Mitigation Strategies
+
+| Strategy | Mechanism | Trade-off |
+|----------|-----------|-----------|
+| **Compacting GC** (JVM G1/ZGC) | Relocate live objects to eliminate gaps | CPU overhead for copying |
+| **Slab allocation** (Linux kernel, memcached) | Fixed-size slabs for common object sizes | Internal fragmentation for odd sizes |
+| **jemalloc / tcmalloc** | Thread-local caches + size classes | ~2% memory overhead for metadata |
+| **Arena allocation** | Bulk-free eliminates fragmentation by design | Requires phase-based lifetimes |
+| **Huge pages** | 2 MB pages reduce fragmentation at page level | Requires explicit configuration |
+| **Periodic restart** | Reclaim all fragmented memory | Brief downtime; requires load balancing |
+
+---
+
+## 8. Stack vs. Heap Allocation Performance
+
+### 8.1 Fundamental Differences
+
+| Aspect | Stack | Heap |
+|--------|-------|------|
+| Allocation cost | ~0.15 ns (pointer decrement) | 10-75 ns (malloc; allocator-dependent) |
+| Deallocation cost | ~0 ns (pointer increment on return) | 250-1000 ns (free; coalescing, bookkeeping) |
+| Total alloc+dealloc | < 1 ns | 260-1075 ns |
+| Memory limit | 1-8 MB typical thread stack | Limited by available RAM |
+| Fragmentation | None | Grows over time |
+| Lifetime | Automatic; scoped to function | Manual or GC-managed |
+| Thread safety | Inherently thread-local | Requires synchronization |
+| Cache behavior | Excellent: hot stack memory in L1 | Variable: depends on allocation pattern |
+
+Source: [Stack vs Heap Benchmark](https://publicwork.wordpress.com/2019/06/27/stack-allocation-vs-heap-allocation-performance-benchmark/);
+[GitHub - stack-vs-heap-benchmark](https://github.com/spuhpointer/stack-vs-heap-benchmark).
+
+### 8.2 Escape Analysis
+
+Modern compilers and runtimes perform escape analysis to allocate heap-intended
+objects on the stack when they do not outlive their scope.
+
+**Go**: The compiler performs escape analysis at build time. Use `go build -gcflags="-m"` to see decisions. Variables that do not escape are stack-allocated (zero GC overhead).
+
+**JVM**: HotSpot's C2 compiler performs scalar replacement -- decomposing objects into their fields on the stack. Enabled by default; verify with `-XX:+PrintEscapeAnalysis`.
+
+**V8**: TurboFan can allocate short-lived objects in registers or on the stack when escape analysis proves safety.
+
+**Practical impact**: In Go, reducing heap escapes by refactoring function
+signatures (returning values instead of pointers, passing buffers as parameters)
+can reduce GC pressure by 20-50% in allocation-heavy code paths.
+
+---
+
+## 9. Common Bottlenecks and Anti-Patterns
+
+### 9.1 Top Memory Performance Bottlenecks
+
+| Bottleneck | Symptom | Typical Impact | Detection |
+|------------|---------|----------------|-----------|
+| **Memory leaks** | RSS grows monotonically | OOM kill after hours/days | Heap snapshots, RSS trending |
+| **GC pressure** | High GC CPU %, frequent pauses | 10-50% throughput loss | GC logs, `gc_pause_seconds` metric |
+| **Cache misses** | High LLC-miss in perf counters | 10-100x slower data access | `perf stat`, VTune, Instruments |
+| **Memory fragmentation** | Allocation failures despite free memory | Latency spikes from compaction | `/proc/buddyinfo`, jemalloc stats |
+| **False sharing** | Poor multi-thread scaling | 2-10x slower than expected | `perf c2c`, padding experiments |
+| **TLB misses** | High `dTLB-load-misses` | 5-30 ns per access overhead | `perf stat -e dTLB-load-misses` |
+
+### 9.2 Anti-Patterns (With Fixes)
+
+#### Anti-Pattern 1: Object Allocation in Hot Loops
+
+```javascript
+// BAD: Creates a new object every iteration
+function processItems(items) {
+    for (const item of items) {
+        const result = { id: item.id, value: transform(item) }; // Allocation!
+        send(result);
+    }
+}
+
+// GOOD: Reuse a single object
+function processItems(items) {
+    const result = { id: null, value: null };
+    for (const item of items) {
+        result.id = item.id;
+        result.value = transform(item);
+        send(result);
+    }
+}
+```
+
+**Impact**: Reducing allocations in a loop processing 1M items can decrease
+young-gen GC frequency by 80%+ and improve throughput by 15-30%.
+
+#### Anti-Pattern 2: Not Reusing Buffers
+
+```go
+// BAD: Allocates new buffer per request
+func handleRequest(w http.ResponseWriter, r *http.Request) {
+    buf := make([]byte, 32*1024) // 32 KB allocation every request
+    n, _ := r.Body.Read(buf)
+    process(buf[:n])
+}
+
+// GOOD: Pool buffers
+var bufPool = sync.Pool{
+    New: func() interface{} { return make([]byte, 32*1024) },
+}
+
+func handleRequest(w http.ResponseWriter, r *http.Request) {
+    buf := bufPool.Get().([]byte)
+    defer bufPool.Put(buf)
+    n, _ := r.Body.Read(buf)
+    process(buf[:n])
+}
+```
+
+#### Anti-Pattern 3: Holding References Unnecessarily
+
+```java
+// BAD: Cache grows unbounded
+private static final Map<String, UserSession> sessionCache = new HashMap<>();
+
+public void onLogin(UserSession session) {
+    sessionCache.put(session.getId(), session);
+    // Never removed! Classic memory leak.
+}
+
+// GOOD: Use WeakHashMap, LRU eviction, or explicit TTL
+private static final Map<String, UserSession> sessionCache =
+    Collections.synchronizedMap(new LinkedHashMap<>(100, 0.75f, true) {
+        @Override
+        protected boolean removeEldestEntry(Map.Entry<String, UserSession> e) {
+            return size() > MAX_CACHE_SIZE;
+        }
+    });
+```
+
+#### Anti-Pattern 4: String Concatenation in Loops
+
+```python
+# BAD: O(n^2) memory -- each concatenation creates a new string
+result = ""
+for line in lines:
+    result += line + "\n"  # Copies entire string each time
+
+# GOOD: O(n) memory -- join pre-allocates
+result = "\n".join(lines)
+```
+
+For 100,000 lines, the bad pattern allocates ~5 GB cumulatively (triangular sum)
+while the good pattern allocates ~the final string size only.
+
+#### Anti-Pattern 5: Forgetting to Remove Event Listeners
+
+```javascript
+// BAD: Listener leaks the component and its entire closure scope
+class Dashboard {
+    constructor() {
+        window.addEventListener('resize', this.onResize.bind(this));
+    }
+    // Component destroyed but listener keeps it alive
+}
+
+// GOOD: Clean up on destroy
+class Dashboard {
+    constructor() {
+        this._onResize = this.onResize.bind(this);
+        window.addEventListener('resize', this._onResize);
+    }
+    destroy() {
+        window.removeEventListener('resize', this._onResize);
+    }
+}
+```
+
+---
+
+## 10. Before/After Case Studies
+
+### Case Study 1: GC Tuning Reduces P99 Latency by 10x
+
+**System**: Java microservice, 8 GB heap, G1GC, processing 5,000 req/s.
+
+| Metric | Before (G1GC default) | After (ZGC) |
+|--------|----------------------|-------------|
+| P50 latency | 12 ms | 11 ms |
+| P99 latency | 120 ms | 14 ms |
+| P99.9 latency | 450 ms | 18 ms |
+| Max GC pause | 380 ms | 0.8 ms |
+| CPU overhead | Baseline | +8% |
+| Throughput | 5,000 req/s | 4,800 req/s |
+
+**Action**: Switched from G1GC to ZGC (`-XX:+UseZGC -XX:+ZGenerational`).
+P99.9 dropped from 450 ms to 18 ms. The 4% throughput decrease from ZGC's
+concurrent overhead was acceptable given the 25x improvement in tail latency.
+
+### Case Study 2: Cache-Friendly Restructuring Improves Throughput 3.5x
+
+**System**: Particle simulation, 10M particles, iterating over position data.
+
+| Metric | Before (AoS) | After (SoA) |
+|--------|-------------|-------------|
+| Layout | `Particle { x, y, z, mass, color, ... }` (96 bytes) | `Positions { xs[], ys[], zs[] }` + separate arrays |
+| Cache lines per particle (position update) | 2 lines (96 bytes > 64-byte line) | 0.19 lines (8 bytes of 64-byte line, shared) |
+| L1 cache miss rate | 34% | 2% |
+| Position update throughput | 28M particles/sec | 98M particles/sec |
+| Speedup | Baseline | **3.5x** |
+
+**Action**: Restructured from array-of-structs to struct-of-arrays for the hot
+position-update loop. The SoA layout meant only x, y, z floats were loaded into
+cache (12 bytes per particle), not the unused mass/color/metadata fields (84 bytes
+wasted per particle in AoS).
+
+### Case Study 3: Memory Leak Fix Prevents Daily OOM Restarts
+
+**System**: Node.js API server, 2 GB heap limit.
+
+| Metric | Before | After |
+|--------|--------|-------|
+| RSS at startup | 180 MB | 180 MB |
+| RSS after 24 hours | 1,950 MB (near OOM) | 220 MB |
+| Required restarts | Every 18-24 hours | None |
+| Root cause | Event listeners on WebSocket connections never removed | Added `ws.removeAllListeners()` on disconnect |
+
+**Detection method**: Captured three heap snapshots at 1-hour intervals using
+`v8.writeHeapSnapshot()`. Comparison showed `Closure` objects growing by 12,000
+per hour, all retained by WebSocket event listener chains. Each closure retained
+~4 KB of scope data, totaling ~48 MB/hour of leaked memory.
+
+---
+
+## 11. Decision Tree: "My App Uses Too Much Memory"
+
+```
+START: App memory is too high
+|
++-> Is memory growing over time (monotonically)?
+|   |
+|   +-> YES: Likely a MEMORY LEAK
+|   |   |
+|   |   +-> Take heap snapshots at T=0, T+5min, T+15min
+|   |   +-> Compare snapshots: which object types are growing?
+|   |   +-> Check for:
+|   |       - Unbounded caches/maps (add eviction policy)
+|   |       - Event listeners not removed (add cleanup)
+|   |       - Closures capturing large scopes (narrow captures)
+|   |       - Goroutine/thread leaks (check blocked routines)
+|   |       - Circular references without weak refs
+|   |
+|   +-> NO: Memory is high but stable
+|       |
+|       +-> Is GC running frequently (high CPU)?
+|       |   |
+|       |   +-> YES: GC PRESSURE
+|       |   |   |
+|       |   |   +-> Check allocation rate (alloc bytes/sec)
+|       |   |   +-> Profile hot allocation sites
+|       |   |   +-> Reduce allocations:
+|       |   |       - Reuse buffers (sync.Pool, object pool)
+|       |   |       - Pre-allocate collections with capacity
+|       |   |       - Move allocations out of hot loops
+|       |   |       - Use stack allocation (escape analysis)
+|       |   |   +-> Tune GC:
+|       |   |       - JVM: increase young gen, tune -XX:MaxGCPauseMillis
+|       |   |       - Go: increase GOGC, set GOMEMLIMIT
+|       |   |       - Node.js: increase --max-semi-space-size
+|       |   |       - Python: gc.freeze() long-lived objects
+|       |   |
+|       |   +-> NO: Legitimate high memory usage
+|       |       |
+|       |       +-> Is the working set larger than available RAM?
+|       |       |   |
+|       |       |   +-> YES: CAPACITY ISSUE
+|       |       |   |   - Add more RAM
+|       |       |   |   - Shard data across instances
+|       |       |   |   - Use off-heap storage (memory-mapped files)
+|       |       |   |   - Move cold data to disk/SSD
+|       |       |   |
+|       |       |   +-> NO: INEFFICIENT DATA STRUCTURES
+|       |       |       - Audit data structure overhead
+|       |       |       - Java: HashMap entry = 32-48 bytes overhead per entry
+|       |       |       - Consider primitive collections (Eclipse Collections,
+|       |       |         fastutil) to avoid boxing: 4 bytes vs 16 bytes per int
+|       |       |       - Use compact representations (byte[] vs String)
+|       |       |       - Consider struct-of-arrays layout
+|       |       |       - Check for duplicate data that can be interned
+|       |
+|       +-> Is memory fragmented (alloc failures despite free space)?
+|           |
+|           +-> YES: FRAGMENTATION
+|               - Switch to jemalloc/tcmalloc
+|               - Use arena allocation for phase-based workloads
+|               - Enable huge pages to reduce page-level fragmentation
+|               - Consider periodic process restart with graceful drain
+|               - JVM: ZGC/Shenandoah compact automatically
+```
+
+---
+
+## 12. Memory Profiling Methodology
+
+### Step-by-Step Production Profiling
+
+**Phase 1: Baseline Measurement**
+1. Record RSS, heap used, and heap committed at startup (after warmup).
+2. Record GC frequency, pause durations, and allocation rate.
+3. Establish baseline under representative load using tools like k6 or Artillery.
+
+**Phase 2: Load Testing**
+1. Run sustained load for 30-60 minutes minimum (leaks need time to manifest).
+2. Monitor heap-used-after-GC trend (should be flat for a non-leaking app).
+3. Record peak RSS and compare to container memory limit (leave 20% headroom).
+
+**Phase 3: Snapshot Analysis**
+1. Capture heap snapshot during steady state.
+2. Capture second snapshot after 15-30 minutes under load.
+3. Use comparison/diff view to identify growing objects.
+4. Focus on **retained size deltas**, not shallow size.
+
+**Phase 4: Allocation Profiling**
+1. Enable allocation tracking (JFR, `--prof`, pprof).
+2. Identify top allocation sites by volume (bytes/sec).
+3. Determine if allocations are necessary or can be eliminated/pooled.
+4. Verify fixes with A/B benchmarks under identical load.
+
+### Tool Quick Reference
+
+```bash
+# JVM: capture heap dump
+jcmd <pid> GC.heap_dump /tmp/heap.hprof
+
+# JVM: live heap histogram (no dump file needed)
+jmap -histo:live <pid> | head -30
+
+# Node.js: capture heap snapshot programmatically
+node -e "require('v8').writeHeapSnapshot()"
+
+# Go: capture heap profile
+curl http://localhost:6060/debug/pprof/heap > heap.pb.gz
+go tool pprof heap.pb.gz
+
+# Python: track allocations
+python -c "
+import tracemalloc
+tracemalloc.start()
+# ... your code ...
+snapshot = tracemalloc.take_snapshot()
+for stat in snapshot.statistics('lineno')[:10]:
+    print(stat)
+"
+
+# Linux: check memory fragmentation
+cat /proc/buddyinfo
+cat /proc/pagetypeinfo
+
+# Linux: check process memory breakdown
+cat /proc/<pid>/smaps_rollup
+pmap -x <pid>
+```
+
+---
+
+## 13. Quick Reference: Numbers Every Engineer Should Know
+
+| Operation | Time | Relative to L1 |
+|-----------|------|-----------------|
+| L1 cache reference | ~1 ns | 1x |
+| L2 cache reference | ~4 ns | 4x |
+| L3 cache reference | ~10 ns | 10x |
+| Main memory (RAM) | ~100 ns | 100x |
+| SSD random read | ~100 us | 100,000x |
+| HDD random read | ~10 ms | 10,000,000x |
+| Stack allocation | ~0.15 ns | <1x |
+| Heap allocation (malloc) | ~40-75 ns | 40-75x |
+| Heap deallocation (free) | ~250-1000 ns | 250-1000x |
+| Arena allocation | ~9-12 ns | 9-12x |
+| Pool allocation | ~9 ns | 9x |
+| System allocator (Box) | ~71-74 ns | 71-74x |
+| Context switch | ~1-10 us | 1,000-10,000x |
+| Mutex lock/unlock | ~25 ns | 25x |
+
+---
+
+## 14. Key Takeaways
+
+1. **Know your hierarchy**: The 100x latency gap between L1 cache (1 ns) and RAM
+   (100 ns) means data layout often matters more than algorithmic complexity for
+   in-memory workloads.
+
+2. **Measure before tuning GC**: Default GC settings are well-tuned for general
+   workloads. Profile with GC logs before changing parameters. Pick two of three:
+   latency, throughput, footprint.
+
+3. **ZGC is transformative for tail latency**: Sub-millisecond pauses regardless
+   of heap size, at a cost of 5-10% CPU overhead. If your JVM service has P99
+   latency requirements, ZGC is the first lever to pull.
+
+4. **Allocation avoidance beats allocation optimization**: Reusing buffers,
+   pre-allocating collections, and keeping objects on the stack (via escape
+   analysis) eliminates GC work entirely.
+
+5. **SoA > AoS for iteration-heavy workloads**: Restructuring data from
+   array-of-structs to struct-of-arrays routinely yields 2-4x throughput
+   improvements by maximizing cache-line utilization.
+
+6. **Leaks are detected by trend, not threshold**: Monitor heap-used-after-GC
+   over time. A monotonically increasing line is the definitive leak signal.
+
+7. **Arena allocation eliminates fragmentation**: For workloads with clear
+   phase-based lifetimes (per-request, per-frame), arenas deliver 7-8x faster
+   allocation and zero fragmentation.
+
+8. **False sharing is the silent multi-threaded killer**: Pad contended data
+   structures to cache-line boundaries. Use `perf c2c` on Linux to detect it.
+
+---
+
+## Sources
+
+- [CPU Cache - Wikipedia](https://en.wikipedia.org/wiki/CPU_cache)
+- [Daniel Lemire - Measuring Cache Line Size](https://lemire.me/blog/2023/12/12/measuring-the-size-of-the-cache-line-empirically/)
+- [Java Code Geeks - G1 vs ZGC vs Shenandoah](https://www.javacodegeeks.com/2025/08/java-gc-performance-g1-vs-zgc-vs-shenandoah.html)
+- [Gunnar Morling - Lower Java Tail Latencies With ZGC](https://www.morling.dev/blog/lower-java-tail-latencies-with-zgc/)
+- [Datadog - Deep Dive into Java GC](https://www.datadoghq.com/blog/understanding-java-gc/)
+- [LinkedIn Engineering - GC Optimization](https://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications)
+- [V8 Blog - Trash Talk: Orinoco GC](https://v8.dev/blog/trash-talk)
+- [Platformatic - V8 GC Optimization](https://blog.platformatic.dev/optimizing-nodejs-performance-v8-memory-management-and-gc-tuning)
+- [Go GC Guide](https://go.dev/doc/gc-guide)
+- [Go Performance Guide - GC](https://goperf.dev/01-common-patterns/gc/)
+- [Python gc Module Documentation](https://docs.python.org/3/library/gc.html)
+- [Artem Golubin - Python GC Internals](https://rushter.com/blog/python-garbage-collector/)
+- [Chrome DevTools - Heap Snapshots](https://developer.chrome.com/docs/devtools/memory-problems/heap-snapshots)
+- [Microsoft Azure - RESIN Memory Leak Detection](https://azure.microsoft.com/en-us/blog/advancing-memory-leak-detection-with-aiops-introducing-resin/)
+- [DZone - Array vs Linked List Performance](https://dzone.com/articles/performance-of-array-vs-linked-list-on-modern-comp)
+- [arXiv - RIP Linked List](https://arxiv.org/html/2306.06942v2)
+- [Wikipedia - AoS and SoA](https://en.wikipedia.org/wiki/AoS_and_SoA)
+- [Medium - Arena Allocators 50-100x Performance](https://medium.com/@ramogh2404/arena-and-memory-pool-allocators-the-50-100x-performance-secret-behind-game-engines-and-browsers-1e491cb40b49)
+- [Ryan Fleury - Untangling Lifetimes: Arena Allocator](https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator)
+- [PingCAP - Linux vs Memory Fragmentation](https://www.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-1/)
+- [Webtide - Object Pooling Benchmarks](https://webtide.com/object-pooling-benchmarks-and-another-way/)
+- [Stack vs Heap Benchmark](https://publicwork.wordpress.com/2019/06/27/stack-allocation-vs-heap-allocation-performance-benchmark/)
+- [Browserless - Memory Leak Guide](https://www.browserless.io/blog/memory-leak-how-to-find-fix-prevent-them)
+- [Halodoc - Fix Node.js Memory Leaks](https://blogs.halodoc.io/fix-node-js-memory-leaks/)
+- [AlgoCademy - Cache-Friendly Data Structures](https://algocademy.com/blog/cache-friendly-algorithms-and-data-structures-optimizing-performance-through-efficient-memory-access/)
+- [Serge Skoredin - Cache-Friendly Go](https://skoredin.pro/blog/golang/cpu-cache-friendly-go)