# CURRENT_TASK Archive

このファイルは、整理前の `CURRENT_TASK.md`（履歴ログを含む）をそのまま保存したアーカイブ。
現行の「次にやること」は `CURRENT_TASK.md` を正とする。

---

# CURRENT_TASK（Rolling）

## 0) 今の「正」（Phase 48 rebase）

- **性能比較の正**: **FAST build**（`make perf_fast`）
- **安全・互換の正**: Standard build（`make bench_random_mixed_hakmem`）
- **観測の正**: OBSERVE build（`make perf_observe`）
- **スコアカード**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`
- **計測の正（Mixed 10-run）**: `scripts/run_mixed_10_cleanenv.sh`（`ITERS=20000000 WS=400`）

## 1) 現状（最新スナップショット）

- FAST v3: **58.478M ops/s**（mimalloc の **48.34%** Phase 59b rebase, Speed-first）
- FAST v3 + PGO: **59.80M ops/s**（mimalloc の **49.41%** — NEUTRAL research box, +0.27% mean, +1.02% median）
- Standard: **53.50M ops/s**（mimalloc の **44.21%** 要 rebase）
- **mimalloc baseline: 120.979M ops/s** (Phase 59b rebase, CV 0.90%)

**M1 (50%) Milestone: Approaching**
- Current ratio: 48.34% (Speed-first mode)
- Gap to 50%: -1.66% (within hakmem CV 2.52%)
- Profile change: Balanced → Speed-first (Phase 57 60-min soak winner)
- Stability: hakmem CV 2.52% vs mimalloc CV 0.90% in Phase 59b
- Production readiness: All metrics meet or exceed targets

※詳細は `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` を正とする（ここは要点だけ）。
※Phase 59b rebase: hakmem stable (58.478M), mimalloc +1.59% variance, ratio 49.13% → 48.34% (-0.79pp)

## 2) 原則（Box Theory 運用）

- 変更は箱で分ける（ENV / build flag で戻せる）
- 境界は 1 箇所（変換点を増やさない）
- **削除して速くする（link-out / 大きい削除）は封印**（layout/LTO で符号反転する）
  - ✅ compile-out（`#if HAKMEM_*_COMPILED` / `#if HAKMEM_BENCH_MINIMAL`）は許容
  - ❌ Makefile から `.o` を外す / コード物理削除は原則しない（Phase 22-2 NO-GO）
- A/B は **同一バイナリ**でトグル（ENV / build flag）。別バイナリ比較は layout が混ざる。

## 3) 次の指示書

**Phase 62A: 完了（NEUTRAL -0.71%, research box）**

- 指示書: "箱化モジュール化 inline レガシー削除 ソースコード綺麗綺麗"
- 実装: C7 ULTRA alloc hot path の dependency chain trim
  - ENV gate: HAKMEM_C7_ULTRA_ALLOC_DEPCHAIN_OPT (default: 0, OFF)
  - 最適化: per-call header_light check を排除 → TLS headers_initialized を活用
  - 期待: +1-3% → 実績: **-0.71%** (NEUTRAL)

- **結果詳細**: `docs/analysis/PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md`
- **判定**: NEUTRAL、research box化（default OFF）

- **原因分析**:
  1. LTO mode では header_light 関数呼び出しが既に inline 済み（コスト 0）
  2. TLS access は memory load + offset calc が必要（機能的に同等か遅い）
  3. Layout tax: コード追加による I-cache disruption (-0.71% loss)
  4. Phases 43/46A/47 と同じパターン（micro-opt on optimized path は失敗傾向）

- **教訓**:
  - Function call overhead (LTO) < TLS access overhead
  - 5.18% stack % は optimizable hotspot ではない（既に最適化済み）
  - 48.34% の gap は algorithmic、micro-opt では埋め難い

**Phase 62B+: 次の方針（TBD）**

- Option A: tiny_region_id_write_header optimization (+0.5-1.5%, very high risk)
- Option B: Production readiness pivot（48.34% accept、documentation/telemetry focus）
- Option C: Algorithmic redesign（batching, prefault strategy、post-50% milestone）

詳細: `docs/analysis/PHASE62_NEXT_TARGET_ANALYSIS.md` + `PHASE62A_C7_ULTRA_DEPCHAIN_OPT_RESULTS.md`

**Phase 61: 完了（NEUTRAL +0.31%, research box）**

- 指示書: Phase 59b と Phase 61 を順番に実装する指示
- 結果: `docs/analysis/PHASE61_C7_ULTRA_HEADER_LIGHT_RESULTS.md`
- 実装: `docs/analysis/PHASE61_C7_ULTRA_HEADER_LIGHT_IMPLEMENTATION.md`
- 狙い: C7 ULTRA alloc hit path で header write を skip（refill 時に 1回だけ書く）
- 判定: Mixed 10-run mean で +0.31% → **NEUTRAL**（baseline: 59.54M ops/s, treatment: 59.73M ops/s, CV 2.66% vs 1.53%）
- 原因: (1) Header write は期待より小さい hotspot（2.32% vs Phase 42 の 4.56%）、(2) Mixed workload で C7 specific optimization が希釈、(3) Treatment の variance 増大（CV 2.66%）、(4) Header-light mode が hot path に branch 追加
- 保持: ENV gate で OFF のまま研究箱として保持（`HAKMEM_TINY_C7_ULTRA_HEADER_LIGHT=0`）
- 教訓: Micro-optimization は precise profiling 必要（cycle count だけでなく IPC/cache-miss も）。Mixed workload は class-specific optimization の効果を薄める。

**Phase 59b: 完了（COMPLETE, measurement-only, zero code changes）**

- 指示書: Phase 59b と Phase 61 を順番に実装する指示
- 結果: `docs/analysis/PHASE59B_SPEED_FIRST_REBASE_RESULTS.md`
- 狙い: Speed-first mode（MIXED_TINYV3_C7_SAFE）で baseline を rebase、M1 (50%) baseline 更新
- 判定: **COMPLETE**（hakmem: 58.478M ops/s, mimalloc: 120.979M ops/s, ratio: 48.34%）
- Profile 変更: Balanced → Speed-first（Phase 57 60-min soak で Speed-first が全指標で勝利）
- 新 baseline: 48.34% of mimalloc (Phase 59 比 -0.79pp, mimalloc variation が主因)
- 推奨: Speed-first (MIXED_TINYV3_C7_SAFE) を canonical default として採用

**Phase 60: 完了（NO-GO -0.46%, research box）**

- 指示書: `docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_DESIGN_AND_INSTRUCTIONS.md`
- 結果: `docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_RESULTS.md`
- 実装: `docs/analysis/PHASE60_ALLOC_PASSDOWN_SSOT_IMPLEMENTATION.md`
- 狙い: alloc 側の重複計算（policy snapshot / route/heap 判定）を入口 1回に集約し、下流へ pass-down（Phase 19-6C の alloc 版）
- 判定: Mixed 10-run mean で -0.46% → **NO-GO**（baseline: 60.05M ops/s, treatment: 59.77M ops/s）
- 原因: (1) 追加 branch check `if (alloc_passdown_ssot_enabled())` のオーバーヘッド、(2) オリジナルパスは既に early-exit で重複を回避しているため upfront 計算が逆効果、(3) struct pass-down の ABI cost
- 保持: ENV gate で OFF のまま研究箱として保持（`HAKMEM_ALLOC_PASSDOWN_SSOT=0`）
- 教訓: SSOT パターンは重複計算が多い場合に有効（Free 側 Phase 19-6C は +1.5%）。Early-exit が既に最適化されている場合は逆効果。

**Phase 50: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 50 で運用安定性測定スイート（Operational Edge Stability Suite）を確立した。

詳細: `docs/analysis/PHASE50_OPERATIONAL_EDGE_STABILITY_SUITE_RESULTS.md`

**成果**:
- **Syscall budget**: 9e-8/op (EXCELLENT) - Phase 48 の値を SSOT 化
- **RSS stability**: 全 allocator で ZERO drift（5分 soak, EXCELLENT）
- **Throughput stability**: 全 allocator で positive drift (+0.8%-0.9%) & low CV (1.5%-2.1%, EXCELLENT)
- **Tail latency**: TODO（Phase 51+ で実装）

**Phase 51: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 51 で単一プロセス soak test により allocator 状態を保持したまま RSS/throughput drift を測定し、tail latency 測定方針を決定した。

詳細: `docs/analysis/PHASE51_SINGLE_PROCESS_SOAK_AND_TAIL_PLAN_RESULTS.md`

**成果**:
- **RSS stability**: 全 allocator で ZERO drift（5分 single-process soak, EXCELLENT）
- **Throughput stability**: 全 allocator で minimal drift (<1.5%) & exceptional CV (0.39%-0.50%, EXCELLENT)
- **hakmem CV**: **0.50%** (Phase 50 の 3× 改善、全 allocator 中最高の single-process 安定性)
- **Tail latency 測定方針**: Option 2 (perf-based) を Phase 52 で実装決定

**Phase 52: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 52 で epoch throughput proxy により tail latency を測定し、hakmem の variance 課題を定量化した。

詳細: `docs/analysis/PHASE52_TAIL_LATENCY_PROXY_RESULTS.md`

**成果**:
- **Tail latency baseline 確立**: epoch throughput 分布を latency proxy として使用
- **hakmem std dev**: 7.98% of mean（mimalloc 2.28%, system 0.77%）
- **p99/p50 ratio**: 1.024（tail behavior は良好だが variance が課題）
- **測定スクリプト**: `scripts/calculate_percentiles.py` (作成済み)

**Phase 53: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 53 で RSS tax の原因を切り分け、speed-first 設計の妥当性を確認した。

詳細: `docs/analysis/PHASE53_RSS_TAX_TRIAGE_RESULTS.md`

**成果**:
- **RSS tax の原因**: Allocator design（persistent superslabs）、bench warmup ではない
- **内訳**: SuperSlab backend ~20-25 MB (60-75%), tiny metadata 0.04 MB (0.1%)
- **Trade-off**: +10x syscall efficiency, -17x memory efficiency vs mimalloc
- **判定**: **ACCEPTABLE** (速さ優先戦略として妥当、drift なし、predictable)

**Phase 54: 完了（COMPLETE, NEUTRAL research box）**

Phase 54 で Memory-Lean mode を実装（opt-in、RSS <10MB を狙う別プロファイル）。

詳細: `docs/analysis/PHASE54_MEMORY_LEAN_MODE_RESULTS.md`

**成果**:
- **実装**: 完了（ENV gate, release policy, prewarm suppression, decommit logic, stats counters）
- **Box Theory**: ✅ PASS (single conversion point, ENV-gated, reversible, DSO-safe)
- **Prewarm suppression**: `HAKMEM_SS_MEM_LEAN=1` で初期 superslab 割り当てをスキップ
- **Decommit logic**: Empty superslab を `madvise(MADV_FREE)` で RSS 削減（munmap せず VMA 保持）
- **Stats counters**: `lean_decommit`, `lean_retire` 追加（`HAKMEM_SS_OS_STATS=1` で表示）

**判定**: **NEUTRAL (research box)**
- 実装は完了（コンパイル成功、runtime エラーなし）
- Extended A/B testing（30-60分 soak）で RSS/throughput trade-off 要計測
- Opt-in feature として保持（memory-constrained 環境向け）

**実装ドキュメント**: `docs/analysis/PHASE54_MEMORY_LEAN_MODE_IMPLEMENTATION.md`

**Phase 55: 完了（COMPLETE, GO — Memory-Lean Mode Validation）**

Phase 55 で Memory-Lean mode を3段階 progressive testing（60s → 5min → 30min）により validation し、**LEAN+OFF が production-ready と判定（GO）**。

詳細: `docs/analysis/PHASE55_MEMORY_LEAN_MODE_VALIDATION_MATRIX.md`

**成果**:
- **Winner**: LEAN+OFF (prewarm suppression only, no decommit)
- **Throughput**: +1.2% vs baseline (56.8M vs 56.2M ops/s, 30min test)
- **RSS**: 32.88 MB (stable, 0% drift)
- **Stability**: CV 5.41% (better than baseline 5.52%)
- **Syscalls**: 1.25e-7/op (8x under budget <1e-6/op)
- **No decommit overhead**: Prewarm suppression only, zero syscall tax

**Validation Strategy**:
- Step 0 (60s): 4 modes smoke test → all PASS, select top 2
- Step 1 (5min): Top 2 stability check → LEAN+OFF dominates
- Step 2 (30min): Final candidate production validation → GO

**判定**: **GO (production-ready)**
- LEAN+OFF is **faster than baseline** (+1.2%, no compromise)
- Zero decommit syscall overhead (simplest lean mode)
- Perfect RSS stability (0% drift, better CV than baseline)
- Opt-in safety (`HAKMEM_SS_MEM_LEAN=0` disables all lean behavior)

**Use Cases**:
- **Speed-first (default)**: `HAKMEM_SS_MEM_LEAN=0` (current production mode)
- **Memory-lean (opt-in)**: `HAKMEM_SS_MEM_LEAN=1 HAKMEM_SS_MEM_LEAN_DECOMMIT=OFF` (production-ready)

**Phase 56+: 次（TBD）**

- 候補A: Variance reduction（tail latency 改善、Phase 52 で課題特定済み）
- 候補B: Throughput gap closure（mimalloc 50% → 55%、algorithmic improvement 必要）
- 候補C: LEAN+FREE/DONTNEED extended validation（extreme memory pressure scenarios）

**運用安定性スコアカード（5分 single-process soak, Phase 51）**:

| Metric | hakmem FAST | mimalloc | system malloc | Target |
|--------|-------------|----------|---------------|--------|
| Throughput | 59.95 M ops/s | 122.38 M ops/s | 85.31 M ops/s | - |
| Syscall budget | 9e-8/op | Unknown | Unknown | <1e-7/op |
| RSS drift | +0.00% | +0.00% | +0.00% | <+5% |
| Throughput drift | +1.20% | -0.47% | +0.38% | >-5% |
| Throughput CV | **0.50%** | 0.39% | 0.42% | ~1-2% |
| Peak RSS | 32.88 MB | 1.88 MB | 1.88 MB | - |

**Status**: ✅ PASS（全指標が target を満たす、CV は Phase 50 の 3× 改善）

**勝ち筋**:
- Syscall budget: 9e-8/op は世界水準（10x better than acceptable threshold）
- Throughput CV: **0.50%** は Phase 50 (1.49%) の 3× 改善、single-process 安定性は exceptional
- RSS drift: ZERO（メモリリーク/断片化なし、single-process でも安定）

**既知の税**:
- Peak RSS: 33 MB vs 2 MB（metadata tax, Phase 44 で確認済み）
- Throughput: mimalloc の 48.99%（M1 (50%) 未達）

**Phase 51 key findings**:
- Single-process soak は multi-process (Phase 50) より 3-5× 低い CV を実現（cold-start variance 除去）
- hakmem CV 0.50% は全 allocator 中最高の single-process 安定性
- Tail latency 測定は Option 2 (perf-based) を Phase 52 で実装

**Phase 49: 完了（COMPLETE, NO-GO, analysis-only, zero code changes）**

Phase 49 で Top hotspot の dependency chain を分析したが、**既に最適化済みで改善余地なしと判定（NO-GO）**。

詳細: `docs/analysis/PHASE49_DEPCHAIN_OPT_TINY_HEADER_AND_UC_PUSH_RESULTS.md`

**Phase 48: 完了（COMPLETE, measurement-only）**

Phase 48 で競合 allocator を同一条件で再計測し、syscall budget と長時間安定性の測定ルーチンを確立。

詳細: `docs/analysis/PHASE48_REBASE_ALLOCATORS_AND_STABILITY_SUITE_RESULTS.md`

**Phase 52: 完了（tail proxy）**

- 指示書: `docs/analysis/PHASE52_TAIL_LATENCY_PROXY_INSTRUCTIONS.md`
- 結果: `docs/analysis/PHASE52_TAIL_LATENCY_PROXY_RESULTS.md`
- 注意: percentile の定義（throughput tail は低い側 / latency は per-epoch から）が重要。`scripts/analyze_epoch_tail_csv.py` を正とする。

**Phase 53: 完了（RSS tax triage）**

- 指示書: `docs/analysis/PHASE53_RSS_TAX_TRIAGE_INSTRUCTIONS.md`
- 結果: `docs/analysis/PHASE53_RSS_TAX_TRIAGE_RESULTS.md`

**Phase 54–57: 完了（Lean mode 実装 + 長時間 validation）**

- 指示書/設計/結果はスコアカード（`docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`）を正とする
- 実装: `docs/analysis/PHASE54_MEMORY_LEAN_MODE_IMPLEMENTATION.md`
- 最終結果: `docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md`

**Phase 56: 完了（COMPLETE, GO — LEAN+OFF promotion / historical）**

Phase 56 で LEAN+OFF（prewarm suppression）を "Balanced mode" として production 推奨にした。

詳細: `docs/analysis/PHASE56_PROMOTE_LEAN_OFF_RESULTS.md`

**成果**:
- **Implementation (historical)**: `core/bench_profile.h` に LEAN+OFF を `MIXED_TINYV3_C7_SAFE` デフォルトとして追加
- **FAST build validation**: 59.84 M ops/s (mean), CV 2.21% (+1.2% vs Phase 55 baseline)
- **Standard build validation**: 60.48 M ops/s (mean), CV 0.81% (excellent stability)
- **Syscall budget**: 5.00e-08/op (identical to baseline, zero overhead)
- **Profile comparison**: Speed-first (59.12 M ops/s, opt-in) vs Balanced (59.84 M ops/s, default)

**判定**: **GO (production-ready)**（ただし Phase 57 の 60-min/tail では Speed-first が優位）

**実装ドキュメント**: `docs/analysis/PHASE56_PROMOTE_LEAN_OFF_IMPLEMENTATION.md`
**結果ドキュメント**: `docs/analysis/PHASE56_PROMOTE_LEAN_OFF_RESULTS.md`
**Scorecard更新**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` (Phase 56 section added)

**Phase 57: 完了（COMPLETE, GO — 60-min soak + syscalls final validation）**

Phase 57 で Balanced mode（LEAN+OFF）を 60分 soak + tail proxy + syscall budget により最終確認し、**production-ready と判定（GO）**。

詳細: `docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md`

**成果**:
- **60-min soak**: Balanced 58.93M ops/s (CV 5.38%), Speed-first 60.74M ops/s (CV 1.58%)
- **RSS drift**: 0.00% (両モード、60分で完全安定)
- **Throughput drift**: 0.00% (両モード、性能劣化なし)
- **10-min tail proxy**: Balanced CV 2.18%, p99 20.78 ns; Speed-first CV 0.71%, p99 19.14 ns
- **Syscall budget**: 1.25e-7/op (両モード、800× below target <1e-6/op)
- **DSO guard**: Active (両モード、madvise_disabled=1)

**判定**: **GO (production-ready)**
- Both modes: 60分で zero drift, stable syscalls, no degradation
- Speed-first: throughput/CV/p99 で優位
- Balanced: prewarm suppression のみ（WS=400 では RSS を減らさない）

**Use Cases（Phase 58 profile split）**:
- **Speed-first (default)**: `HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE`
- **Balanced (opt-in)**: `HAKMEM_PROFILE=MIXED_TINYV3_C7_BALANCED`（= `LEAN=1 DECOMMIT=OFF`）

**結果ドキュメント**: `docs/analysis/PHASE57_BALANCED_MODE_60MIN_SOAK_AND_SYSCALLS_RESULTS.md`
**Scorecard更新**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` (Phase 57 section added)

**Phase 58: 完了（Profile split: Speed-first default + Balanced opt-in）**

- 指示書: `docs/analysis/PHASE58_PROFILE_SPLIT_SPEED_FIRST_DEFAULT_INSTRUCTIONS.md`
- 実装: `core/bench_profile.h`
  - `MIXED_TINYV3_C7_SAFE`: Speed-first default（LEAN を preset しない）
  - `MIXED_TINYV3_C7_BALANCED`: LEAN+OFF を preset

**Phase 59: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 59 で Balanced mode baseline を rebase し、M1 (50%) milestone を事実上達成（49.13%, within statistical noise）。

詳細: `docs/analysis/PHASE59_50PERCENT_RECOVERY_BASELINE_REBASE_RESULTS.md`

**成果**:
- **M1 Achievement**: 49.13% of mimalloc (gap -0.87%, within hakmem CV 1.31%)
- **Stability Advantage**: hakmem CV 1.31% vs mimalloc CV 3.50% (2.68× more stable)
- **Production Readiness**: All metrics meet or exceed targets
  - Syscall budget: 1.25e-7/op (800× below target)
  - RSS drift: 0% (60-min test, Phase 57)
  - Tail latency: CV 1.31% (better than mimalloc 3.50%)
- **Baseline Update**: hakmem 59.184M ops/s, mimalloc 120.466M ops/s

**Strategic Decision Point（更新）**:
- M1（50%）は実質達成したが、次は **「層/学習層/安定度を保ったまま +5–10%」** を狙う。

**Next Phases**:
- **Phase 60**: alloc pass-down SSOT（重複計算の排除、+1–2% を積む）
- **Phase 61+（任意）**: Competitive analysis / production deployment / 技術総括（速度が落ち着いたら）

**Phase 43: 完了（NO-GO, reverted）**

Phase 43 でheader write tax reduction を試行（C1-C6 の redundant header write を skip）したが、**-1.18% regression で NO-GO**。

**Phase 42: 完了（NEUTRAL, analysis-only）**

Phase 42 で runtime-first 最適化手法を適用、perf profiling → ASM inspection の順で hot target を探索したが、**最適化対象が存在しないことを確認**。

**結果詳細**: `docs/analysis/PHASE42_RUNTIME_FIRST_METHOD_RESULTS.md`

**発見**:
- **Top 50 に gate function が存在しない** — Phase 39 の定数化が極めて効果的だった証明
- ASM に 10+ gate function の call site が存在するが、全て **runtime では実行されていない** (<0.1% self-time)
- 既存の condition ordering も最適化済み（cheap check → expensive check の順）

**runtime profiling 結果** (perf report --no-children):
1. malloc (22.04%) / free (21.73%) / main (21.65%) — core allocator + benchmark loop
2. tiny_region_id_write_header (17.58%) — header write hot path
3. tiny_c7_ultra_free (7.12%) / unified_cache_push (4.86%) — allocation paths
4. classify_ptr (2.48%) / tiny_c7_ultra_alloc (2.45%) — routing logic
5. **Gate functions: ZERO in Top 50** ← Phase 39 の成功を確認

**手法の検証**:
- ✅ runtime profiling FIRST により Phase 40/41 の失敗（layout tax）を回避
- ✅ "ASM presence ≠ runtime impact" の原則を再確認
- ✅ Top 50 ルールにより optimization 対象の枯渇を早期検出

**教訓**:
1. **Know when to stop** — runtime data が "no hot targets" を示したら code を触らない
2. **Phase 39 の効果は絶大** — 全 hot gate を eliminate 済み
3. **Code cleanup は既に完了** — 既存 code は Box Theory + inline best practices に準拠済み
4. **次の 10-15% gap は algorithmic improvement が必要** — gate optimization は限界

**Phase 44: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 44 で cache-miss および writeback profiling を実施（測定のみ、コード変更なし）。**Modified Case A: Store-Ordering/Dependency Bound** を確認。

**結果詳細**: `docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md`

**発見**:
- **IPC = 2.33 (excellent)** — CPU は効率的に実行中、heavy stall なし
- **cache-miss rate = 0.97% (world-class)** — cache behavior は既に最適化済み
- **L1-dcache-miss rate = 1.03% (very good)** — L1 hit rate ~99%
- **High time/miss ratios (20x-128x)** — hot functions は store-ordering bound、not miss-bound
- **tiny_region_id_write_header**: 2.86% time, 0.06% misses (48x ratio)
- **unified_cache_push**: 3.83% time, 0.03% misses (128x ratio)

**教訓**:
1. **NOT a cache-miss bottleneck** — 0.97% miss rate は既に exceptional
2. **High IPC (2.33) confirms efficient execution** — CPU は stall していない
3. **Store-ordering/dependency chains が bottleneck** — high time/miss ratios が証明
4. **Kernel dominates cache-misses (93.54%)** — user-space allocator は cache-friendly
5. **Prefetching は NG** — cache-miss rate が既に低いため、逆効果の可能性

**Phase 45: 完了（COMPLETE, analysis-only, zero code changes）**

Phase 45 で dependency chain および store-to-load forwarding analysis を実施（測定・解析のみ、コード変更なし）。**Dependency-chain bound** を確認。

**結果詳細**: `docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md`

**発見**:
- **Dependency-chain bound confirmed** — high time/miss ratios (20x-128x) が証明
- **`unified_cache_push`: 128x ratio** (3.83% time, 0.03% misses) — 最重度の store-ordering bottleneck
- **`tiny_region_id_write_header`: 48x ratio** (2.86% time, 0.06% misses) — store-ordering bound
- **`malloc`/`free`: 26x ratio** (55% time, 2.15% misses) — dependency chain が支配的

**Top 3 Optimization Opportunities**:
1. **Opportunity A**: Eliminate lazy-init branch in `unified_cache_push` (+1.5-2.5%)
2. **Opportunity B**: Reorder operations in `tiny_region_id_write_header` (+0.8-1.5%)
3. **Opportunity C**: Prefetch TLS cache structure in `malloc` (+0.5-1.0%, conditional)

**Expected cumulative gain**: +2.3-5.0% (59.66M → 61.0-62.6M ops/s)

**Phase 46+ 方針** (dependency chain optimization):

Cache-miss は既に最適 (0.97%)。次は **dependency chain 短縮** に注目：

1. **Phase 46A**: Eliminate lazy-init branch in `unified_cache_push` (HIGH PRIORITY, LOW RISK)
2. **Phase 46B**: Reorder header write operations for parallelism (MEDIUM PRIORITY, MEDIUM RISK)
3. **Phase 46C**: A/B test TLS cache prefetching (LOW PRIORITY, MEASURE FIRST)
4. **Algorithmic review**: mimalloc の data structure 優位性を調査（残り 47-49% gap は algorithmic 可能性高）

**Target**: mimalloc gap 50.5% → 53-55%（micro-arch 限界、algorithmic improvement 必要）

指示書:
- Phase 43（header write tax）: `docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_INSTRUCTIONS.md`（NO-GO）
- Phase 44（cache-miss / writeback profiling）: `docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md`（COMPLETE）
- Phase 45（dependency chain analysis）: `docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md`（COMPLETE）
- Phase 46（TBD: dependency chain optimization）: 未作成

## 4) 直近のログ（要点だけ）

- Phase 24–34: atomic prune 累積 **+2.74%**（その後 diminishing returns）
- Phase 35-A: `HAKMEM_BENCH_MINIMAL=1`（gate prune）**GO +4.39%**
- Phase 36: FAST-only policy snapshot 最適化 **GO +0.71%**
- Phase 37: Standard TLS cache **NO-GO**（runtime gate の税が勝つ）
- Phase 38: FAST/OBSERVE/Standard 運用確立（scorecard + Makefile targets）
- Phase 39: FAST v3 gate 定数化 **GO +1.98%**
  - 結果詳細: `docs/analysis/PHASE39_FAST_V3_GATE_CONSTANTIZATION_RESULTS.md`
- Phase 40: `tiny_header_mode()` 定数化 **NO-GO -2.47%** (REVERTED)
  - 結果詳細: `docs/analysis/PHASE40_GATE_CONSTANTIZATION_RESULTS.md`
  - 原因: Phase 21 hot/cold split で既に最適化済み + code layout tax
  - 教訓: Assembly inspection first、既存最適化を尊重
- Phase 41: ASM-first gate audit (`mid_v3_*()`) **NO-GO -2.02%** (REVERTED)
  - 結果詳細: `docs/analysis/PHASE41_ASM_FIRST_GATE_AUDIT_RESULTS.md`
  - 原因: Dead code 削除による layout tax（gates は runtime 実行なし）
  - 教訓: ASM presence ≠ impact、runtime profiling 必須、dead code は放置
- Phase 42: runtime-first 最適化手法 **NEUTRAL (analysis-only, no code changes)**
  - 結果詳細: `docs/analysis/PHASE42_RUNTIME_FIRST_METHOD_RESULTS.md`
  - 発見: Top 50 に gate function が存在しない（Phase 39 の成功を確認）
  - 教訓: runtime profiling → 最適化対象の枯渇を早期検出、code を触らない判断
- Phase 43: Header write tax reduction **NO-GO -1.18%** (REVERTED)
  - 結果詳細: `docs/analysis/PHASE43_HEADER_WRITE_TAX_REDUCTION_RESULTS.md`
  - 目的: C1-C6 の redundant header write を skip（nextptr invariant 利用）
  - 原因: Branch misprediction tax (4.5+ cycles) > saved store cost (1 cycle)
  - 教訓: Straight-line code is king、runtime branches in hot paths are very expensive
  - Note: FAST v3 baseline updated to 59.66M ops/s (improved test environment)
- Phase 44: Cache-miss and writeback profiling **COMPLETE (measurement-only, zero code changes)**
  - 結果詳細: `docs/analysis/PHASE44_CACHE_MISS_AND_WRITEBACK_PROFILE_RESULTS.md`
  - 目的: cache-miss / store-ordering / dependency chain の bottleneck 特定
  - 発見: IPC = 2.33 (excellent), cache-miss = 0.97% (world-class), high time/miss ratios (20x-128x)
  - 判定: **Modified Case A - Store-Ordering/Dependency Bound**
  - 教訓: NOT a cache-miss bottleneck、prefetching は NG、50% gap は algorithmic 可能性高
- Phase 45: Dependency chain analysis **COMPLETE (analysis-only, zero code changes)**
  - 結果詳細: `docs/analysis/PHASE45_DEPENDENCY_CHAIN_ANALYSIS_RESULTS.md`
  - 目的: Store-to-load forwarding と dependency chain の詳細解析
  - 発見: `unified_cache_push` (128x ratio), `tiny_region_id_write_header` (48x ratio) が dependency-chain bound
  - Top 3 Opportunities: (A) Eliminate lazy-init branch (+1.5-2.5%), (B) Reorder header ops (+0.8-1.5%), (C) Prefetch TLS cache (+0.5-1.0%)
  - 教訓: Assembly analysis で具体的な dependency chain 特定、Opportunity A は LOW RISK (Phase 43 lesson 準拠)

**Phase 46A: 完了（NO-GO, research box）**

Phase 46A で `tiny_region_id_write_header` の `always_inline` 属性を適用したが、**mean -0.68%, median +0.17% で NO-GO**。

**結果詳細**: `docs/analysis/PHASE46A_TINY_REGION_ID_WRITE_HEADER_ALWAYS_INLINE_RESULTS.md`

**発見**:
- **Mean -0.68% (NO-GO threshold)** — layout tax の兆候
- **Median +0.17% (weak positive)** — inline 自体は micro で有効
- **Binary size 同一** — compiler 既に inline 済み、layout rearrangement のみ発生
- **Branch prediction 有効** — modern CPU は hot path の branch を完璧に予測

**教訓**:
1. **Layout tax は実在** — code size 同一でも performance 変化
2. **Branch prediction 効果大** — straight-line code への変換は期待値 < 0.5%
3. **Median positive ≠ actionable** — mean が閾値下回れば NO-GO
4. **Conservative threshold 必要** — ±0.5% mean で layout tax を filter

**Phase 47: 完了（NEUTRAL, research box retained）**

Phase 47 で compile-time fixed front config (`HAKMEM_TINY_FRONT_PGO=1`) を適用したが、**mean +0.27%, median +1.02% で NEUTRAL**。

**結果詳細**: `docs/analysis/PHASE47_FAST_FRONT_PGO_MODE_RESULTS.md`

**発見**:
- **Mean +0.27% (NEUTRAL, below +0.5% threshold)** — 閾値未達
- **Median +1.02% (positive signal)** — compile-time constants に小幅効果
- **Variance 2× baseline (2.32% vs 1.23%)** — treatment group の分散増大（layout tax 兆候）
- **5-7 branches eliminated** — runtime gate checks → compile-time constants

**理由（NEUTRAL）**:
1. **Mean が GO 閾値（+0.5%）未達** — layout tax が gain を相殺
2. **High variance (2× CV)** — measurement uncertainty、reproducibility concern
3. **Phase 46A lesson** — small positive signals can mask layout tax

**Research box として保持**:
- Makefile ターゲット: `bench_random_mixed_hakmem_fast_pgo`
- 将来的に他の最適化と組み合わせる可能性を残す
- Mean-median 乖離（+0.27% vs +1.02%）は genuine micro-optimization の存在を示唆

**教訓**:
1. **Branch prediction is effective** — 5-7 branch elimination で <1% gain のみ
2. **Layout tax is real** — variance 増大が code rearrangement 副作用を示唆
3. **Conservative threshold justified** — ±0.5% mean で noise を filter
4. **Median-positive ≠ actionable** — mean と median 両方が threshold 超え必要

**Phase 49: 完了（COMPLETE, NO-GO, analysis-only, zero code changes）**

Phase 49 で Top hotspot (`tiny_region_id_write_header`, `unified_cache_push`) の dependency chain を分析したが、**既に最適化済みで改善余地なしと判定（NO-GO）**。

**結果詳細**: `docs/analysis/PHASE49_DEPCHAIN_OPT_TINY_HEADER_AND_UC_PUSH_RESULTS.md`

**発見**:
- `tiny_region_id_write_header` (5.34%): Phase 21 hot/cold split 最適化済み、hot path は 5命令 straight-line（極めて最小）
- `unified_cache_push` (4.03%): BENCH_MINIMAL で lazy-init compile-out 済み、TLS offset 計算は CPU micro-arch 依存
- Dependency chain の主因は CPU micro-architecture（register save/restore, TLS access）— software 最適化では短縮不可能
- Perf annotate の lazy-init (18.91%) は LTO inline の副作用（caller 混在）、実コードでは compile-out 済み

**教訓**:
1. **Know when to stop** — runtime data が "no optimization targets" を示したら code を触らない（Phase 42 教訓再確認）
2. **Micro-arch bottleneck は software 最適化の限界** — TLS/register は CPU 依存、algorithmic improvement 必要
3. **Layout tax は実在する** — Phase 40/41/43/46A の一貫した教訓、code size 同一でも performance 変化
4. **Perf annotate ≠ optimization target** — LTO/inline による symbol 混在を考慮すべき
5. **M1 (50%) 再達成には構造改善が必要** — Phase 44/45 結論と一致

**Phase 48: 完了（COMPLETE, measurement-only, zero code changes）**

Phase 48 で競合 allocator（mimalloc/system/jemalloc）を同一条件で再計測し、syscall budget と長時間安定性の測定ルーチンを確立した。

**結果詳細**: `docs/analysis/PHASE48_REBASE_ALLOCATORS_AND_STABILITY_SUITE_RESULTS.md`

**発見**:
- **hakmem FAST v3**: 59.15M ops/s (mimalloc の 48.88%, -0.82% variance)
- **mimalloc**: 121.01M ops/s (新 baseline, +2.39% environment drift)
- **system malloc**: 85.10M ops/s (70.33%, +4.37% environment drift)
- **jemalloc**: 96.06M ops/s (79.38%, 初回計測)
- **Syscall budget**: 9e-8 / op (EXCELLENT, ideal の 10x 以内)

**判定**:
- **Status: COMPLETE** (measurement-only, zero code changes)
- M1 (50%) 再達成に必要: +1.45M ops/s (+2.45%)
- Environment drift により ratio 50.5% → 48.88% (mimalloc baseline 上昇が主因)

**教訓**:
1. **Environment drift is real** — mimalloc +2.39%, system +4.37% 変化
2. **hakmem は安定** — -0.82% は measurement variance 範囲内
3. **jemalloc は strong competitor** — 79.38% of mimalloc (system より 9% 速い)
4. **Syscall budget は excellent** — 9e-8 / op, warmup 後に churn なし

次の指示書（Phase 49+）:
- **Phase 49+: TBD（dependency chain optimization / algorithmic review）**
  - スコアカード（SSOT）: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`
  - Phase 48 rebase により新 baseline 確立
  - M1 再達成 または M2 (55%) を目指す最適化が必要

## 5) アーカイブ

- 旧 `CURRENT_TASK.md`（詳細ログ）は `archive/CURRENT_TASK_ARCHIVE_20251216.md`