Phase 74-1/74-2: UnifiedCache LOCALIZE optimization (P1 frozen, NEUTRAL -0.87%)

Phase 74-1 (ENV-gated LOCALIZE):
- Result: +0.50% (NEUTRAL)
- Runtime branch overhead caused instructions/branches to increase
- Diagnosed: Branch tax dominates intended optimization

Phase 74-2 (compile-time LOCALIZE):
- Result: -0.87% (NEUTRAL, P1 frozen)
- Removed runtime branch → instructions -0.6%, branches -2.3% ✓
- But cache-misses +86% (register pressure/spill) → net loss
- Conclusion: LOCALIZE本体 works, but fragile to cache effects

Key finding:
- Dependency chain reduction (LOCALIZE) has low ROI due to cache-miss sensitivity
- P1 (LOCALIZE) frozen at default OFF
- Next: Phase 74-3 (P0: FASTAPI) - move branches outside hot loop

Files:
- core/hakmem_build_flags.h: HAKMEM_TINY_UC_LOCALIZE_COMPILED flag
- core/box/tiny_unified_cache_hitpath_env_box.h: ENV gate (frozen)
- core/front/tiny_unified_cache.h: compile-time #if blocks
- docs/analysis/PHASE74_*: Design, instructions, results
- CURRENT_TASK.md: P1 frozen, P0 next instructions

Also includes:
- Phase 69 refill tuning results (archived docs)
- PERFORMANCE_TARGETS_SCORECARD.md: Phase 69 baseline update
- PHASE70_REFILL_OBSERVABILITY_PREREQS_SSOT.md: Route banner docs

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

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

CURRENT_TASK.md

@@ -1,236 +1,89 @@
 # CURRENT_TASK（Rolling, SSOT）
 
-## 0) 今の「正」
+## 0) 今の「正」（SSOT）
 
-- **性能比較の正**: FAST PGO build（`make pgo-fast-full` → `bench_random_mixed_hakmem_minimal_pgo`）✓ **Phase 69 昇格済み** (Warm Pool Size=16)
+- **性能比較の正**: FAST PGO build（`make pgo-fast-full` → `bench_random_mixed_hakmem_minimal_pgo`）＋ **WarmPool=16**（Phase 69 強GOで昇格済み）
 - **安全・互換の正**: Standard build（`make bench_random_mixed_hakmem`）
 - **観測の正**: OBSERVE build（`make perf_observe`）
-- **スコアカード**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`（M1 達成・超過: 51.77% vs 50% target、M2 まで残り +3.23pp）
-- **計測の正（Mixed 10-run）**: `scripts/run_mixed_10_cleanenv.sh`（`ITERS=20000000 WS=400`、`HAKMEM_WARM_POOL_SIZE=16` デフォルト）
+- **スコアカード（目標/現在値）**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`
+  - Current baseline（FAST v3 + PGO, Phase 69）: **62.63M ops/s = 51.77% of mimalloc**
+  - 次の目標: **M2 = 55%**（残り **+3.23pp**）
+- **Mixed 10-run SSOT**: `scripts/run_mixed_10_cleanenv.sh`（`ITERS=20000000 WS=400`、`HAKMEM_WARM_POOL_SIZE=16` デフォルト）
 
-## 1) 現状（要点）
+## 1) 迷子防止（経路/観測）
 
-- Phase 64（backend prune / DCE）: **NO-GO**（-4.05%） → layout tax 由来
-- Phase 63（FAST_PROFILE_FIXED）: **研究用ビルド**として保持（FAST の gate を compile-time 固定）
-- Phase 65（Hot Symbol Ordering）: **BLOCKED**（GCC+LTO の制約で不公平/不可能）→ `docs/analysis/PHASE65_HOT_SYMBOL_ORDERING_1_RESULTS.md`
-- Phase 66（PGO, GCC+LTO）: **GO** ✓
-  - 検証: 3回独立実行で +3.0% mean, all >+2.89%, 分散 <±1%
-  - Baseline: `bench_random_mixed_hakmem_minimal_pgo` = 60.89M ops/s = 50.32% (initial PGO)
-- Phase 68（PGO training set 最適化）: **GO & 昇格完了** ✓
-  - 検証: 10-run で +1.19% vs Phase 66 (GO: +1.0% threshold超過)
-  - Baseline (upgraded): `bench_random_mixed_hakmem_minimal_pgo` = 61.614M ops/s = **50.93%** (50% target 超過、+0.93pp)
-- Phase 69（Refill tuning: Warm Pool Size 最適化）: **強GO & 昇格完了** ✓✓✓
-  - 検証: 10-run で +3.26% vs Phase 68 (強GO: +3.0% threshold超過)
-  - 新 baseline: `bench_random_mixed_hakmem_minimal_pgo` (upgraded) = 62.63M ops/s = **51.77%** (M1 超過、+1.77pp、M2 まで残り +3.23pp)
+“経路が踏まれていない最適化” を防ぐための最小手順。
 
-## 2) 次の指示書（Active）
+- **Route Banner（経路の誤認を潰す）**: `HAKMEM_ROUTE_BANNER=1`
+  - 出力: Route assignments（backend route kind）+ cache config（`unified_cache_enabled` / `warm_pool_max_per_class`）
+- **Refill観測のSSOT**: `docs/analysis/PHASE70_REFILL_OBSERVABILITY_PREREQS_SSOT.md`
+  - WS=400（Mixed SSOT）では miss が極小 → `unified_cache_refill()` 最適化は **凍結（ROIゼロ）**
 
-**Phase 68: PGO training set 最適化** ✅ **完了**
+## 2) 直近の結論（要点だけ）
 
-- ✓ seed/WS diversification: WS (3→5パターン), seed (1→3パターン)
-- ✓ 10-run 検証: +1.19% vs Phase 66 (GO threshold +1.0% 超過)
-- ✓ Baseline 昇格: 61.614M ops/s = 50.93% (M1 target 50% を +0.93pp 超過)
-- ✓ スコアカード・CURRENT_TASK 更新完了
-
----
-
-**Phase 67a: Layout Tax 法医学（変更最小）** ✅ **完了・実運用可能**
-
-- ✓ `scripts/box/layout_tax_forensics_box.sh` 新規（測定ハーネス）
-  - Baseline vs Treatment の 10-run throughput 比較
-  - perf stat 自動収集（cycles, IPC, branches, branch-misses, cache-misses, iTLB/dTLB）
-  - Binary metadata（サイズ、セクション構成）
-
-- ✓ `docs/analysis/PHASE67A_LAYOUT_TAX_FORENSICS_SSOT.md` 新規（診断ガイド）
-  - 判定ルール: GO (+1% 以上) / NEUTRAL (±1%) / NO-GO (-1% 以下)
-  - "症状→原因候補" マッピング表
-    * IPC 低下 3%↑ → I-cache miss / code layout dispersal
-    * branch-misses ↑10%↑ → branch prediction penalty
-    * dTLB-misses ↑100%↑ → data layout fragmentation
-  - Phase 64 case study（-4.05% の root cause: IPC 2.05 → 1.98）
-  - 運用ガイドライン
-
-**使用例**:
-```bash
-./scripts/box/layout_tax_forensics_box.sh \
-    ./bench_random_mixed_hakmem_minimal_pgo \
-    ./bench_random_mixed_hakmem_fast_pruned  # or Phase 64 attempt
-```
-
-成果: 「削る系」NO-GO が出た時に、どの指標が悪化しているかを **1回で診断可能** → 以後の link-out/大削除を事前に止められる
-
----
-
-**Phase 69: "refill頻度×固定税" を削る（M2への最短距離）**
-
-**Phase 69-0: パラメータ sweep 設計メモ** ✅ **完了**
-
-- ✓ `docs/analysis/PHASE69_REFILL_TUNING_0_DESIGN.md` 作成
-- ✓ Tunable parameters 特定:
-  - `HAKMEM_TINY_REFILL_COUNT_MID` / `HAKMEM_TINY_REFILL_COUNT_HOT`（refill 量の実体, ENV-only）
-  - Unified Cache C5-C7 capacity (128 → 256/512)
-  - Warm Pool size (12 → 16/24)
-- ✓ Sweep 計画立案（single-parameter → combined optimization）
-- ✓ Risk assessment & 判定基準定義
-
-**Phase 69-1: Sweep 実行** ✅ **完了**
-
-- ✓ Baseline (Phase 68 PGO): 60.65M ops/s (10-run mean)
-- ✓ Warm Pool Size sweep:
-  - Size=16: **62.63M ops/s (+3.26%, 強GO)** ✓✓✓ **Winner**
-  - Size=24: 62.37M ops/s (+2.84%, GO)
-- ✓ Unified Cache C5-C7 sweep:
-  - Cache=256: 61.92M ops/s (+2.09%, GO)
-  - Cache=512: 61.80M ops/s (+1.89%, GO)
-- ✓ Combined optimization check:
-  - Warm=16 + Cache=256: 62.35M ops/s (+2.81%, non-additive)
-- ✓ “Refill Batch Size sweep” は無効（knob 未接続）:
-  - `TINY_REFILL_BATCH_SIZE` は現行 Tiny front に call site が無く、性能 knob として成立していない
-  - 参照: `docs/analysis/PHASE69_REFILL_TUNING_3C_REFILL_BATCH_KNOB_AUDIT.md`
-- **結果**: `docs/analysis/PHASE69_REFILL_TUNING_1_RESULTS.md`
-- **勝ち設定**: **Warm Pool Size=16 (ENV-only, +3.26%, 強GO)**
-
-**Phase 69-2: 勝ち設定を baseline に反映** ✅ **完了**
-
-- ✓ `scripts/run_mixed_10_cleanenv.sh` に `HAKMEM_WARM_POOL_SIZE=16` デフォルト追加
-- ✓ `core/bench_profile.h` の `MIXED_TINYV3_C7_SAFE` preset に `bench_setenv_default("HAKMEM_WARM_POOL_SIZE","16")` 追加
-- ✓ `PERFORMANCE_TARGETS_SCORECARD.md` に新 baseline 追加:
-  - Phase 69 baseline: 62.63M ops/s = 51.77% of mimalloc
-  - M1 (50%) achievement: **EXCEEDED** (+1.77pp above target)
-  - M2 (55%) progress: Gap reduced to +3.23pp
-- ✓ Rollback: `HAKMEM_WARM_POOL_SIZE=12` or ENV 変数削除
-
-**新 baseline**: 62.63M ops/s = mimalloc の **51.77%** (Phase 68 から +3.26%、M2 まで残り +3.23pp)
-
----
-
-**Phase 69-3（次候補）: refill 量（ENV-only）sweep OR 次の sweep**
-
-- **選択肢 A（推奨）**: Refill count の ENV sweep（コード変更なし）
-  - `HAKMEM_TINY_REFILL_COUNT_MID`（C4–C7）を 64/96/128/160… で sweep
-  - `HAKMEM_TINY_REFILL_COUNT_HOT`（C0–C3）も同様に sweep（ただし WarmPool/UnifiedCache と相互作用あり）
-  - 判定: 10-run mean で GO(+1.0%) / 強GO(+3.0%) / NO-GO(-1.0%)
-
-- **選択肢 B**: Unified Cache の fine sweep（ENV-only）
-  - C5/C6/C7 を 192/256/320… などで sweep（Phase 69-1 の 256/512 は coarse）
-  - WarmPool=16 との非加算性を “原因切り分け” する
-
-- **選択肢 C**: compile-time knob の新設（後回し）
-  - `TINY_REFILL_BATCH_SIZE` は未接続なので、そのまま追わない
-  - 必要なら別途 SSOT を作って実装する（Phase 70+）
-
-- **選択肢 D**: 別方向の最適化（M2: 55% への最短距離）
-  - 残り gap: +3.23pp (51.77% → 55%)
-  - Phase 67b（境界 inline/unroll チューニング）
-  - Top 50 hot functions の最適化
-  - PGO profile の再調整
-
----
-
-**Phase 67b（後続・保険）: 境界inline/unrollチューニング**
-- **注意**: layout tax リスク高い（Phase 64 reference）
-- **前提**: Top 50 実行確認が必須
-- Phase 69 が外れた時の保険として後回し推奨
-
----
-
-**Phase 70（観測の前提固め）: Refill/WarmPool 最適化の Step 0 を SSOT 化**
-
-- 目的: **“経路が踏まれていない最適化”** を防ぐ（Phase 40/41/64 の layout tax 前例）
-- 注意: `Route assignments: LEGACY` は「Unified Cache 未使用」を意味しない（backend route kind）
-- SSOT: `docs/analysis/PHASE70_REFILL_OBSERVABILITY_PREREQS_SSOT.md`
-  - Mixed SSOT（WS=400）で `unified_cache_refill()` / WarmPool pop が有意に起きているかを **OBSERVE で確定**してから Phase 70 を進める
-- ✅ Phase 70-1: Route Banner 実装（経路誤認の根絶）
-  - ENV: `HAKMEM_ROUTE_BANNER=1`
-  - 出力: Route assignments（backend route kind）+ cache config（unified_cache / warm_pool_max_per_class）
-- ✅ Phase 70-3: OBSERVE 統計の整合性 SSOT（“見えてないだけ”事故の根絶）
-  - `Unified-STATS total_allocs == total_frees` を確認してから議論する（統計の信頼性ゲート）
-- ✅ Phase 70-2: Refill 最適化の扱い確定（SSOT）
-  - Mixed SSOT（WS=400）で `Unified-STATS miss < 1000` なら **Refill 最適化は凍結（ROIゼロ）**
-  - 現状の実測: miss は極小（例: total miss=5）→ refill最適化は SSOT workload では ROI なし
+- **Phase 69（WarmPool sweep）**: `HAKMEM_WARM_POOL_SIZE=16` が **強GO（+3.26%）**、baseline 昇格済み。
+  - 設計: `docs/analysis/PHASE69_REFILL_TUNING_0_DESIGN.md`
+  - 結果: `docs/analysis/PHASE69_REFILL_TUNING_1_RESULTS.md`
+- **Phase 70（観測SSOT）**: 統計の見える化/前提ゲート確立。WS=400 SSOT では refill は冷たい。
+  - SSOT: `docs/analysis/PHASE70_REFILL_OBSERVABILITY_PREREQS_SSOT.md`
+- **Phase 71/73（WarmPool=16 の勝ち筋確定）**: 勝ち筋は **instruction/branch の微減**（perf stat で確定）。
   - 詳細: `docs/analysis/PHASE70_71_WARMPOOL16_ANALYSIS.md`
+- **Phase 72（ENV knob ROI枯れ）**: WarmPool=16 を超える ENV-only 勝ち筋なし → **構造（コード）で攻める段階**。
 
----
+## 3) 運用ルール（Box Theory + layout tax 対策）
 
-**Phase 73: WarmPool=16 の "勝ち筋" を perf で確定** ✅ **完了・パラドックス解決**
+- 変更は必ず **箱 + 境界1箇所 + ENVで戻せる** で積む（Fail-fast、最小可視化）。
+- A/B は **同一バイナリでENVトグル**が原則（別バイナリ比較は layout が混ざる）。
+- “削除して速い” は封印（link-out/大削除は layout tax で符号反転しやすい）→ **compile-out** を優先。
+  - 診断: `scripts/box/layout_tax_forensics_box.sh` / `docs/analysis/PHASE67A_LAYOUT_TAX_FORENSICS_SSOT.md`
 
-- 背景: WarmPool=16 は throughput/CV を改善するが、Unified/WarmPool 等の可視カウンタはほぼ同一 → **「1回あたりのコスト差」**（TLB/LLC/周波数/配置）の可能性が高い
-- 目的: WarmPool=12 vs 16 の差分を **perf stat** で "何が減ったか" に落とし、次の構造最適化（Phase 72）を決め打ちする
-- 方式: **同一バイナリ + cleanenv + 交互実行**（layout tax/環境ドリフトを避ける）
-  - A: `HAKMEM_WARM_POOL_SIZE=12`
-  - B: `HAKMEM_WARM_POOL_SIZE=16`
-  - events: `cycles,instructions,branches,branch-misses,cache-misses,LLC-load-misses,iTLB-load-misses,dTLB-load-misses,page-faults`
+## 4) 次の指示書（Active）
 
-**結果**（パラドックス）:
-- ✅ Throughput: +0.91% (46.52M → 46.95M ops/s)
-- ✅ **instructions**: -0.38% (-17.4M instructions) ← **PRIMARY WIN SOURCE**
-- ✅ **branches**: -0.30% (-3.7M branches) ← **SECONDARY WIN SOURCE**
-- ⚠️ **dTLB-load-misses**: +29.06% (28,792 → 37,158) ← **WORSE**
-- ⚠️ **cache-misses**: +17.80% (458K → 540K) ← **WORSE**
-- ✓ page-faults: -0.21% (negligible)
+### Phase 74（構造）: UnifiedCache hit-path を短くする ✅ **P1 (LOCALIZE) 凍結**
 
-**Phase 71 仮説（REJECTED）**:
-- 予測: "TLB/cache efficiency improvement from memory layout"
-- 実測: TLB/cache metrics both **DEGRADED**
+**前提**:
+- WS=400 SSOT では UnifiedCache miss が極小 → refill最適化は ROIゼロ。
+- WarmPool=16 の勝ちは instruction/branch 微減 → hit-path を短くするのが正攻法。
 
-**Phase 73 確定**:
-- 勝ち筋: **Control-flow optimization (instruction/branch count reduction)**
-- 機構: WarmPool=16 がより短い code path を選択 → 17.4M instructions 削減
-- Trade-off: +4MB RSS → worse TLB/cache, but instruction savings dominate
-- Net benefit: ~8.2M cycles saved (instruction/branch) >> ~4.2M cycles lost (TLB/cache)
+**Phase 74-1: LOCALIZE (ENV-gated)** ✅ **完了 (NEUTRAL +0.50%)**
+- ENV: `HAKMEM_TINY_UC_LOCALIZE=0/1`
+- Runtime branch overhead で instructions/branches **増加** (+0.7%/+0.4%)
+- 判定: **NEUTRAL (+0.50%)**
 
-**詳細**: `docs/analysis/PHASE70_71_WARMPOOL16_ANALYSIS.md` Phase 73 section
+**Phase 74-2: LOCALIZE (compile-time gate)** ✅ **完了 (NEUTRAL -0.87%)**
+- Build flag: `HAKMEM_TINY_UC_LOCALIZE_COMPILED=0/1` (default 0)
+- Runtime branch 削除 → instructions/branches **改善** (-0.6%/-2.3%) ✓
+- しかし **cache-misses +86%** (register pressure / spill) → throughput **-0.87%**
+- 切り分け成功: **LOCALIZE本体は勝ち、cache-miss 増加で相殺**
+- 判定: **NEUTRAL (-0.87%)** → **P1 (LOCALIZE) 凍結**
 
-**Phase 72（構造）: WarmPool=16 の勝ち筋を増幅（Phase 73 結果が出てから）**
+**結論**:
+- P1 (LOCALIZE) は default OFF で凍結（dependency chain 削減の ROI 低い）
+- 次: **Phase 74-3 (P0: FASTAPI)** へ進む
 
-- 前提: Phase 73 で “勝ち筋” を数値で確定してから着手（推測で弄ると Phase 40/41/64 の再発）
-- Phase 73 の結論: **instruction/branch 減が支配的**（TLB/cache はむしろ悪化）→「WarmPool=16 が “短い経路” を踏ませている」ことが本質
+**Phase 74-3: P0 (FASTAPI)** 🟡 **次の指示書**
 
-**Phase 72-0（SSOT）: “どの関数が短くなったか” を特定してから構造に入る**
+**Goal**: `unified_cache_enabled()` / `lazy-init` / `stats` 判定を **hot loop の外へ追い出す**
 
-- A/B は WarmPool=12 vs 16 のまま（同一バイナリ・cleanenv）
-- perf record を **cycles ではなく instruction/branch で取る**（原因が instruction/branch 減だから）
-  - `perf record -e instructions:u -c 100000 -- ./bench_random_mixed_hakmem_observe 20000000 400 1`
-  - `perf record -e branches:u -c 100000 -- ./bench_random_mixed_hakmem_observe 20000000 400 1`
-- 目的: WarmPool=16 で **instruction share / branch share が減った関数 top 3** を確定（例: `shared_pool_acquire_slab`, `unified_cache_refill`, `warm_pool_do_prefill`, `superslab_refill` 等）
+**Approach**:
+- `unified_cache_push_fast()` / `unified_cache_pop_fast()` API 追加
+- 前提: "valid/enabled/no-stats" を caller 側で保証
+- Fail-fast: 想定外の状態なら slow path へ fallback（境界1箇所）
+- ENV gate: `HAKMEM_TINY_UC_FASTAPI=0/1` (default 0, research box)
 
-**Phase 72-1（構造）: 特定した関数にだけ手を入れる（箱の境界 1 箇所化）** ✅ **キャンセル（ROIゼロ）**
+**Expected**: +1-2% via branch reduction (P1 と異なる軸)
 
-- perf record 結果: `unified_cache_push` が -0.86% branches（最大削減）
-- 当初計画: Unified Cache の FULL drain 最適化
-- **キャンセル理由**: 全クラスで `full=0`（FULL イベントが発生していない）→ ROI ゼロ
+**判定**:
+- **GO**: +1.0% 以上
+- **NEUTRAL**: ±1.0%（freeze、次へ）
+- **NO-GO**: -1.0% 以下（即 revert）
 
-**Phase 72-2: WarmPool 追加 sweep** ✅ **完了（ROI枯れ）**
+**参考**:
+- 設計: `docs/analysis/PHASE74_UNIFIEDCACHE_HITPATH_STRUCTURAL_OPT_0_DESIGN.md`
+- 指示書: `docs/analysis/PHASE74_UNIFIEDCACHE_HITPATH_STRUCTURAL_OPT_1_NEXT_INSTRUCTIONS.md`
+- 結果 (P1): `docs/analysis/PHASE74_UNIFIEDCACHE_HITPATH_STRUCTURAL_OPT_2_RESULTS.md`
 
-- 目的: WarmPool=16 以外に勝者がいるか確認
-- Baseline: WarmPool=16 = 56.23M ops/s (10-run)
-- 結果:
-  - WarmPool=20: 56.13M ops/s (**-0.18%**, NO-GO)
-  - WarmPool=24: 56.30M ops/s (**+0.12%**, 誤差範囲)
-  - WarmPool=32: 56.07M ops/s (**-0.28%**, NO-GO)
-- **判定**: 全候補が ±0.5% 以内 → **Phase 72 終了（ENV knob ROI 枯れ）**
-
----
-
-**Phase 72 総括**:
-- **確定**: WarmPool=16 が最適値（Phase 69 で確定、Phase 72 で再確認）
-- **確定**: ENV knob による追加最適化の余地なし
-- **勝ち筋**: instruction/branch 削減が支配的（Phase 73 で確定）
-- **次のステップ**: 構造変更（コード変更）が必要
-
-**注記**: 研究箱の削除は今やらない（link-out/削除が layout tax を起こす前例が強いので、compile-out維持が正解）
-
----
-
-**Phase 74（次候補）: 構造変更による最適化**
-
-- **前提**: ENV knob ROI 枯れ → コード変更が必要
-- **候補 A**: `unified_cache_push` の branch 削減（Phase 72-0 で最大寄与確認済み）
-- **候補 B**: hot path の inline 強化（layout tax リスクあり、要 forensics）
-- **候補 C**: PGO profile 再調整（WarmPool=16 前提で retrain）
-- **判定基準**: +1.0% → GO、+0.5% 未満 → NO-GO
-
-## 3) アーカイブ
+## 5) アーカイブ
 
 - 詳細ログ: `CURRENT_TASK_ARCHIVE_20251210.md`
-- 直近整理前スナップショット: `docs/analysis/CURRENT_TASK_ARCHIVE.md`
+- 整理前スナップショット: `docs/analysis/CURRENT_TASK_ARCHIVE.md`