Split free_tiny_fast() into hot and cold paths to reduce I-cache pressure:
- free_tiny_fast_hot(): always_inline, fast-path validation + ULTRA/MID/V7
- free_tiny_fast_cold(): noinline,cold, cross-thread + TinyHeap + legacy
ENV: HAKMEM_FREE_TINY_FAST_HOTCOLD=0/1 (default 0)
Stats: HAKMEM_FREE_TINY_FAST_HOTCOLD_STATS=0/1 (TLS only, exit dump)
## Benchmark Results (random mixed, 100M ops)
HOTCOLD=0 (legacy): 49.35M, 50.18M, 50.25M ops/s (median: 50.18M)
HOTCOLD=1 (split): 43.54M, 43.59M, 43.62M ops/s (median: 43.59M)
**Regression: -13.1%** (NO-GO)
## Stats Analysis (10M ops, HOTCOLD_STATS=1)
Hot path: 50.11% (C7 ULTRA early-exit)
Cold path: 48.43% (legacy fallback)
## Root Cause
Design assumption FAILED: "Cold path is rare"
Reality: Cold path is 48% (almost as common as hot path)
The split introduces:
1. Extra dispatch overhead in hot path
2. Function call overhead to cold for ~48% of frees
3. "Cold" is NOT rare - it's the legacy fallback for non-ULTRA classes
## Conclusion
**FREEZE as research box (default OFF)**
Box Theory value:
- Validated hot/cold distribution via TLS stats
- Confirmed that legacy fallback is NOT rare (48%)
- Demonstrated that naive hot/cold split hurts when "cold" is common
Alternative approaches for future work:
1. Inline the legacy fallback in hot path (no split)
2. Route-specific specialization (C7 vs non-C7 separate paths)
3. Policy-based early routing (before header validation)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
c503b212a3