Phase FREE-DISPATCHER-OPT-1: free dispatcher 統計計測

**目的**: free dispatcher（29%）の内訳を細分化して計測。

**実装内容**:
- FreeDispatchStats 構造体追加（ENV: HAKMEM_FREE_DISPATCH_STATS, default 0）
- カウンタ: total_calls / domain (tiny/mid/large) / route (ultra/legacy/pool/v6) / env_checks / route_for_class_calls
- hak_free_at / tiny_route_for_class / tiny_route_snapshot_init にカウンタ埋め込み
- 挙動変更なし（計測のみ、ENV OFF 時は overhead ゼロ）

**計測結果**:

Mixed 16-1024B (1M iter, ws=400):
- total=8,081, route_calls=267,967, env_checks=9
- BENCH_FAST_FRONT により大半は早期リターン
- route_for_class は主に alloc 側で呼ばれる（267k calls vs 8k frees）
- ENV check は初期化時の 9回のみ（snapshot 効果）

C6-heavy (257-768B, 1M iter, ws=400):
- total=500,099, route_calls=1,034, env_checks=9
- fg_classify_domain に到達する free が多い
- route_for_class 呼び出しは極小（snapshot 効果）

**結論**:
- ENV check は既に十分最適化されている（初期化時のみ）
- route_for_class は alloc 側での呼び出しが主で、free 側は snapshot で O(1)
- 次フェーズ（OPT-2）では別のアプローチを検討

**ドキュメント追加**:
- docs/analysis/FREE_DISPATCHER_ANALYSIS.md（新規）
- CURRENT_TASK.md に Phase FREE-DISPATCHER-OPT-1 セクション追加

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

docs/status/CURRENT_TASK.md

@@ -220,3 +220,123 @@ Step 2.5 が TLS_SLL_PUSH_DUP を「修正」するために追加されたが
    - master-80M-unstable から Step 2.5 をリバート
    - 複雑な conflict (33行変更) で35+ 回失敗済み
    - 推奨しない
+
+---
+
+## Phase PERF-ULTRA-REBASE-2: C4-C7 ULTRA free最適化後のperf再計測 (2025-12-11)
+
+**計測対象**: Mixed 16-1024B, C6-heavy
+
+### 計測条件
+- **Mixed 16-1024B**:
+  - ENV: `HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE`
+  - ULTRA: C4-C7 全て ON
+  - ワークロード: iters=1M, ws=400
+  - perf: -F 5000 --call-graph dwarf -e cycles:u
+
+- **C6-heavy**:
+  - ENV: `HAKMEM_PROFILE=C6_HEAVY_LEGACY_POOLV1`
+  - pool v1 + C6/C5/C4 ULTRA
+  - ワークロード: 1 thread, iters=1M, ws=400
+
+### スループット
+- **Mixed**: 42.63M ops/s（前回 31.61M から大幅改善、但し ws=400 vs 8192の差）
+- **C6-heavy**: 26.49M ops/s
+
+### 新しい最大ホットスポット（Mixed）
+**WARNING: サンプル数が極めて少ない（238 samples）**
+
+| 順位 | 関数 | self% | 分類 |
+|------|------|-------|------|
+| #1 | free | 27.88% | ベンチマーク wrapper |
+| #2 | tiny_alloc_gate_fast | 23.57% | alloc gate/front |
+| #3 | main | 17.66% | ベンチマーク harness |
+| #4 | malloc | 6.94% | ベンチマーク wrapper |
+| #5 | header 書き込み合計 | 8.07% | tiny_region_id_write_header |
+
+**ULTRA 関連関数が全て不可視**: tiny_c7_ultra_alloc や ULTRA free 群が上位20に入っていない
+
+### 前フェーズ（PERF-ULTRA-FREE-OPT-1）との比較
+- **前回（ws=8192, iters=10M）**: C7 ULTRA alloc 7.66%, ULTRA free群 5.41%, so_alloc 3.60%
+- **今回（ws=400, iters=1M）**: これらが全て不可視（< 0.63%）
+- **サンプル数**: 前回1842 samples vs 今回238 samples（約1/8）
+
+### 結論
+- **計測条件の再検討が必要**: ワークロードが軽すぎ（iters=1M, ws=400）
+  - perf サンプル数が238と極めて少なく、統計的信頼性が低い
+  - ベンチマーク時間が0.023s（23ms）と極めて短く、allocator 本体が可視化されていない
+
+- **次の最大ボトルネックを確定できず**:
+  - gate/front（23.57%）と header（8.07%）が可視範囲での上位
+  - ULTRA alloc/free の実態が見えていない
+
+- **推奨される次の手順**:
+  - iters を 10M に増やす、または ws を 8192 に拡大して再計測
+  - サンプル数を1000+に増やして統計的信頼性を確保
+
+### C6-heavy 分析
+- **pool v1 が支配的**: alloc 14.46% + free 19.89% = 34.35%
+- **ULTRA は可視化されず**: C6/C5/C4 ULTRA 関数が上位に入っていない
+- **pthread_once が8.21%**: 初期化同期のオーバーヘッドが目立つ（ワークロードが軽い証拠）
+
+### 出力物
+1. **perf_ultra_mixed_v2.txt** - Mixed の perf report 完全出力（238 samples）
+2. **perf_ultra_c6_v2.txt** - C6-heavy の perf report 完全出力（292 samples）
+3. **更新済み TINY_CPU_HOTPATH_USERLAND_ANALYSIS.md** - 解析結果とWARNINGを記載
+4. **更新済み CURRENT_TASK.md** - 本セクション
+
+---
+
+## Phase PERF-ULTRA-REBASE-2 後の次フェーズ候補（要判断）
+
+### 判断保留理由
+- **サンプル不足**: 現状の perf 結果では allocator 本体のボトルネックが可視化されていない
+- **再計測が必須**: より重いワークロード（iters=10M, ws=8192）で再測定してから判断すべき
+
+### パターン分析（参考：前回 PERF-ULTRA-REBASE-1 の結果に基づく）
+
+#### パターン A: tiny_c7_ultra_alloc が依然トップの場合
+- **前回の値**: 7.66% self（最大ホットスポット）
+- 理由: ULTRA alloc の内部構造（refill/page_meta）に起因
+- 次フェーズ案: **Phase PERF-ULTRA-REFILL-OPT-1**
+  - C7 ULTRA の refill path（cold 側）を最適化
+  - segment 取得ロジックの軽量化
+  - page_meta 管理の簡略化
+- 判断: C7 refill を弄る技術的難度と効果のバランスを検討
+
+#### パターン B: so_alloc_fast / page_of が浮いてきた場合
+- **前回の値**: so_alloc系 3.60%, page_of系 2.74%
+- 理由: ULTRA が C4-C7 を完全カバーし、v3 backend 側が relative に大きくなった
+- 次フェーズ案: **Phase PERF-ULTRA-V3-OPT-1**
+  - so_alloc_v3 の hotpath 簡略化
+  - page_of（ptr→page 解決）の高速化
+  - header write の最適化（既に thin は確認済み）
+- 判断: v3 backend 自体を軽くするか、別 backend（v4/v6）を考えるか
+
+#### パターン C: 残り legacy (C2/C3) が顕著な場合
+- 確認: legacy 総数が何%か、C2/C3 の比率を確認
+- 判断基準:
+  - C2/C3 合計が全体の 5% 以上 → C3 ULTRA を検討する価値あり
+  - C2/C3 合計が 2% 未満 → 後回し（L1 汚染のリスクが高い）
+
+#### パターン D: tiny_alloc_gate_fast / header が上位の場合（今回観測）
+- **今回の値**: gate 23.57%, header 8.07%
+- 理由: ワークロードが軽すぎて allocator 本体が見えていない可能性が高い
+- 次フェーズ案: **Phase PERF-ULTRA-REBASE-3（再計測）**
+  - より重いワークロード（iters=10M, ws=8192）で再測定
+  - サンプル数1000+を確保して統計的信頼性を高める
+  - その上でパターンA/B/Cのどれかに該当するか判断
+
+### 推奨される判断フロー
+1. **Phase PERF-ULTRA-REBASE-3（再計測）を実施**
+   - iters=10M, ws=8192 で Mixed を再計測
+   - perf record 時間を長くしてサンプル数を確保
+
+2. **再計測後の perf_ultra_mixed_v3.txt の #1/#2 を見る**
+   - パターン A/B/C/D のどれに該当するか判定
+
+3. **該当フェーズ案を実装 or 研究箱化の判断**
+   - A: ULTRA refill 最適化（高難度、効果大）
+   - B: v3 backend 最適化（中難度、効果中）
+   - C: C2/C3 ULTRA 追加（低難度、効果不明）
+   - D: 再計測（必須）