hakmem/docs/analysis/PHASE42_RUNTIME_FIRST_METHOD_RESULTS.md

Phase 42: Runtime-first Optimization Method — Results

Summary

Result: NEUTRAL (No viable optimization targets found)

Phase 42 applied runtime-first profiling methodology to identify hot gates/branches for optimization. The analysis revealed that all ENV gates have already been optimized by Phase 39 or are not executed frequently enough to warrant optimization.

Recommendation: Focus on code cleanup for maintainability. No performance changes proposed.

Step 0: Baseline (FAST v3)

Command: make perf_fast (10-run clean env) Parameters: ITERS=20000000 WS=400

Run 1:  56037241 ops/s
Run 2:  54480534 ops/s
Run 3:  54240352 ops/s
Run 4:  56509163 ops/s
Run 5:  56599857 ops/s
Run 6:  56882712 ops/s
Run 7:  55733565 ops/s
Run 8:  55192809 ops/s
Run 9:  56536602 ops/s
Run 10: 56424281 ops/s

Mean:   55.8637M ops/s
Median: 56.2308M ops/s

Baseline established: 55.86M ops/s (mean), 56.23M ops/s (median)

Step 1: Runtime Profiling (MANDATORY FIRST)

Command: perf record -F 99 -g -- ./bench_random_mixed_hakmem_minimal 20000000 400 1 Purpose: Identify functions actually executed (avoid Phase 41 dead code mistake)

Top Functions by Self-Time (perf report --no-children)

1.  22.04%  malloc
2.  21.73%  free
3.  21.65%  main (benchmark loop)
4.  17.58%  tiny_region_id_write_header.lto_priv.0
5.   7.12%  tiny_c7_ultra_free
6.   4.86%  unified_cache_push.lto_priv.0
7.   2.48%  classify_ptr
8.   2.45%  tiny_c7_ultra_alloc.constprop.0
9.   0.05%  hak_pool_free_v1_slow_impl
10.  0.04%  __rb_insert_augmented (kernel)

Critical Finding: NO GATE FUNCTIONS IN TOP 50

Observation: No *_enabled(), *_mode(), *_snapshot(), or similar gate functions appear in the Top 50.

Interpretation:

• Phase 39 BENCH_MINIMAL constantization already eliminated hot gates
• Remaining gates are either dead code or <0.1% self-time (below noise)
• Runtime confirms Phase 39's effectiveness

Step 2: ASM Inspection (Top 50 candidates only)

Command: objdump -d ./bench_random_mixed_hakmem_minimal | grep -A3 "call.*enabled"

Gate Functions Present in ASM (NOT in Top 50)

Found 10+ gate functions with call sites in ASM, but ZERO in perf Top 50:

1. tiny_guard_enabled_runtime - 2 call sites
2. small_v6_headerless_route_enabled - 1 call site
3. mid_v3_debug_enabled - 3+ call sites (dead code, Phase 41)
4. mid_v3_class_enabled - 1 call site
5. tiny_heap_class_route_enabled - 1 call site
6. tiny_c7_hot_enabled - 2 call sites
7. tiny_heap_stats_enabled - 3+ call sites
8. tiny_heap_box_enabled - 1 call site
9. tiny_heap_meta_ultra_enabled_for_class - 1 call site
10. tiny_page_box_is_enabled - 2 call sites

Analysis

ASM presence ≠ Performance impact (Phase 41 lesson confirmed)

All gates with ASM call sites have <0.1% self-time:

• Either executed rarely (cold path only)
• Or dead code (called but inside if (0) blocks)
• Branch predictor handles them perfectly (zero mispredict cost)

Decision: SKIP optimization - these gates are not hot.

Step 3: Condition Reordering (LOW RISK - PRIORITY)

Status: NO VIABLE TARGETS

Analysis

Reviewed hot path files for condition reordering opportunities:

• core/front/malloc_tiny_fast.h
• core/box/hak_alloc_api.inc.h
• core/box/hak_free_api.inc.h

Findings

All existing conditions already optimized:

• Line 255: if (class_idx == 7 && c7_ultra_on) — cheap check first ✓
• Line 266-267: if ((unsigned)class_idx <= 3u) { if (alloc_dualhot_enabled()) { ... } } — inner gate already constantized to 0 (Phase 39) ✓

No condition reordering needed - existing code already follows best practices.

Step 4: BENCH_MINIMAL Constantization (HIGH RISK - LAST RESORT)

Status: SKIPPED (Prerequisites not met)

Prerequisites Check

• ✗ Function confirmed in Top 50 (Step 1) — FAILED: No gate functions in Top 50
• ✗ Branch/call confirmed in ASM (Step 2) — N/A: Gates exist in ASM but not executed
• ✗ Condition reordering insufficient (Step 3) — N/A: No targets identified

Decision: SKIP Step 4 - no viable constantization targets.

Risk Assessment

Attempting Step 4 would repeat Phase 40/41 mistakes:

• Phase 40: -2.47% from constantizing already-optimized tiny_header_mode()
• Phase 41: -2.02% from removing dead code mid_v3_debug_enabled()

Lesson learned: Don't optimize code that isn't executed (confirmed by perf).

Code Cleanup Summary

1. Dead Code Analysis

Finding: Existing #if 0 blocks are correctly compile-out (Box Theory compliant)

Files with #if 0 blocks:

• core/box/ss_allocation_box.c (line 380): Policy-based munmap guard (legacy)
• core/box/tiny_front_config_box.h (line 133): Debug print (circular dependency)

Action: NONE - already compile-out, no physical deletion needed (Phase 22-2 precedent)

2. Duplicate Inline Helpers

Finding: Multiple definitions of tiny_self_u32 helper:

• core/tiny_refill.h: static inline uint32_t tiny_self_u32(void);
• core/tiny_free_fast_v2.inc.h: static inline uint32_t tiny_self_u32_local(void)
• core/front/malloc_tiny_fast.h: static inline uint32_t tiny_self_u32_local(void)

Analysis:

• Each has guard macro (TINY_SELF_U32_LOCAL_DEFINED)
• LTO eliminates redundant copies at link time
• No runtime impact (already optimized)

Action: Leave as-is - guards prevent conflicts, LTO handles deduplication

3. Inline Function Size

Review: Checked always_inline functions for >50 line threshold

Finding: Most inline functions are appropriately sized:

• malloc_tiny_fast_for_class(): ~130 lines — justified (hot path, single caller)
• free_tiny_fast(): ~300 lines — justified (ultra-hot path, header validation)
• free_tiny_fast_cold(): 160 lines — marked noinline,cold ✓

Action: NONE - existing inline decisions are well-justified

4. Legacy Code Compile-out

Review: Searched for legacy features that could be boxed/compile-out

Finding: All legacy code already behind proper gates:

• Phase 9/10 MONO paths: ENV-gated ✓
• Phase v3/v4/v5 routes: Removed in Phase v10 ✓
• Debug code: Behind !HAKMEM_BUILD_RELEASE ✓

Action: NONE - legacy handling already follows Box Theory

Performance Impact

Optimization changes: NONE (no viable targets found) Code cleanup changes: NONE (existing code already clean)

Final verdict: NEUTRAL (baseline maintained)

Conclusion

Phase 42 Outcome: NEUTRAL (Expected)

Phase 42's runtime-first methodology successfully validated that:

1. Phase 39 was highly effective - eliminated all hot gates
2. Remaining gates are not hot - <0.1% self-time or dead code
3. Current code is already clean - no cleanup needed

Methodology Validation

Runtime-first method (perf → ASM) worked as designed:

• Prevented repeating Phase 40/41 mistakes (layout tax from optimizing cold code)
• Confirmed that ASM presence ≠ runtime impact (Phase 41 lesson)
• Identified that all optimization headroom has been exhausted for gates

Next Steps

For future phases:

1. Focus on algorithmic improvements (not gate optimization)
2. Consider data structure layout (cache line alignment, struct packing)
3. Explore memory access patterns (prefetching, temporal locality)

For Phase 43+:

• Target: ~10-15% gap to mimalloc (56M → 62-65M ops/s)
• Strategy: Profile hot path memory access patterns
• Tool: perf record -e cache-misses for L1/L2/L3 analysis

Files Modified

NONE - Phase 42 was analysis-only, no code changes.

Lessons Learned

1. Runtime profiling is mandatory - ASM inspection alone is insufficient
2. Top 50 rule is strict - optimize only what appears in Top 50
3. Code cleanup has diminishing returns - existing code already follows best practices
4. Know when to stop - not every phase needs to change code

Phase 42 successfully demonstrated the value of doing nothing when runtime data shows no hot targets.