hakmem/archive/CURRENT_TASK_ARCHIVE_20251216.md

# CURRENT_TASK（ARCHIVE: 2025-12-16）

## 現在の状態（要約）

- **安定版（本線）**: Phase 35-A 完了（HAKMEM_BENCH_MINIMAL gate function elimination） — **GO +4.39%**
- **Phase 37 結果**: NO-GO — Standard build TLS cache は効果なし（-0.07%）
- **Phase 38 完了**: FAST/OBSERVE 運用確立（スコアカード更新、Makefile ターゲット追加）
- **直近の判断**:
  - Phase 24（OBSERVE 税 prune / tiny_class_stats）: ✅ GO (+0.93%)
  - Phase 25（Free Stats atomic prune / g_free_ss_enter）: ✅ GO (+1.07%)
  - Phase 26（Hot path diagnostic atomics prune / 5 atomics）: ⚪ NEUTRAL (-0.33%, code cleanliness で採用)
  - Phase 27（Unified Cache Stats atomic prune / 6 atomics）: ✅ GO (+0.74% mean, +1.01% median)
  - Phase 28（Background Spill Queue audit / 8 atomics）: ⚪ NO-OP (全て CORRECTNESS)
  - Phase 29（Pool Hotbox v2 Stats audit / 12 atomics）: ⚪ NO-OP (ENV-gated, 実行されない)
  - Phase 30（Standard Procedure Documentation）: ✅ PROCEDURE COMPLETE (412 atomics 監査完了)
  - Phase 31（Tiny Free Trace atomic prune / g_tiny_free_trace）: ⚪ NEUTRAL (-0.35%, code cleanliness で採用)
  - Phase 32（Tiny Free Calls atomic prune / g_hak_tiny_free_calls）: ⚪ NEUTRAL (-0.46%, code cleanliness で採用)
  - Phase 34（Batch Prune / atomic 一括）: ⚪ NEUTRAL (-0.10%, atomic prune は収穫済み)
  - Phase 35-A（BENCH_MINIMAL gate prune）: ✅ **GO (+4.39%)** — gate function overhead 削除
- **計測の正**: `scripts/run_mixed_10_cleanenv.sh`（同一バイナリ / clean env / 10-run）
- **累積効果**: **+2.74%** (atomic prune) + **+4.39%** (bench_minimal gate prune) = **+7.13%** potential
- **目標/現状スコアカード**: `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md`

## 原則（Box Theory 運用ルール）

- 変更は箱で分ける（ENV / build flag で戻せる）
- 変換点（境界）は 1 箇所に集約する
- "削除して速くする" は危険（layout/LTO で反転する）
  - ✅ compile-out（`#if HAKMEM_*_COMPILED`）は許容
  - ❌ link-out（Makefile から `.o` を外す）は封印（Phase 22-2 NO-GO）
- **Atomic 監査原則**（Phase 30 標準化）:
  - **Step 0: 実行確認（MANDATORY）**: ENV gate / 実行カウンタ確認（Phase 29 教訓）
  - **Step 1: CORRECTNESS vs TELEMETRY 分類**: `if` 条件 = CORRECTNESS（Phase 28 教訓）
  - **Step 2: Compile-out 実装**: `#if HAKMEM_*_COMPILED` で wrap
  - **Step 3: A/B test**: Baseline vs Compiled-in（10-run 比較）
  - **Verdict**: GO (+0.5%+), NEUTRAL (±0.5%), NO-GO (-0.5%+)

## Phase 35-A 完了（2025-12-16）— HAKMEM_BENCH_MINIMAL GO +4.39%

### 背景

Phase 34（Batch Prune）で atomic prune が収穫済み（NEUTRAL -0.10%）と判断。
次の層「固定税の次の層」として、非 atomic 固定オーバーヘッド（gate functions）を対象とした。

### perf 分析で特定した gate function hotspots

1. `tiny_metadata_cache_enabled()` — 1.46% (getenv + lazy init)
2. `tiny_front_v3_enabled()` — 0.65% (getenv + lazy init)
3. 合計潜在削減: ~2.1%+

### 実施内容

**Phase 35-A: HAKMEM_BENCH_MINIMAL=1 アプローチ**

- Build flag で gate functions を compile-time constant に固定
- Bench-only binary を生成（本線リリースビルドは影響なし）
- Box Theory 準拠: ENV gate のまま、bench 専用バイナリで検証

**変更ファイル:**
1. `core/hakmem_build_flags.h` — `HAKMEM_BENCH_MINIMAL` flag 追加
2. `core/box/tiny_metadata_cache_env_box.h` — `#if HAKMEM_BENCH_MINIMAL` で固定 OFF
3. `core/box/tiny_front_v3_env_box.h` — `#if HAKMEM_BENCH_MINIMAL` で固定 ON
4. `Makefile` — `bench_random_mixed_hakmem_minimal` target 追加

### A/B Test 結果

**Baseline (BENCH_MINIMAL=0):**
- Mean: 52,940,947 ops/s (10 runs)

**Minimal (BENCH_MINIMAL=1):**
- Mean: 55,264,082 ops/s (10 runs)

**Improvement:**
- Delta: +2,323,134 ops/s
- **Percent: +4.39%**

### 判定

**GO ✅ (+4.39% > +0.5% threshold)**

**理由:**
1. Gate function overhead は atomic prune より大きい固定税だった
2. `tiny_metadata_cache_enabled()` + `tiny_front_v3_enabled()` の lazy init check が HOT path で毎回実行
3. BENCH_MINIMAL=1 で compile-time constant 化 → lazy init branch 完全削除
4. +4.39% は Phase 24-32 の atomic prune 累積 (+2.74%) より大きい

### 次のステップ（Phase 35 Option C）

**GO 条件達成** → Option C（default=1 検討へ）

指示書の通り、次は:
- gate functions の default を ON (1) に変更する検討
- ただし本線挙動への影響を慎重に評価する必要あり
- `tiny_front_v3_enabled()` は既に default ON
- `tiny_metadata_cache_enabled()` は default OFF（変更検討対象）

### 教訓

1. **Gate functions は高コスト:** lazy init pattern (`if (g == -1)`) は分岐予測ミスを引き起こす
2. **Compile-time constant が最速:** BENCH_MINIMAL で固定 ON/OFF → 分岐完全削除
3. **Atomic prune より効果大:** Phase 34 NEUTRAL (-0.10%) vs Phase 35-A GO (+4.39%)
4. **Build-level optimization は安全:** 本線ビルドに影響なく検証可能

---

## Phase 37 完了（2025-12-16）— Standard TLS cache NO-GO (-0.07%)

### 背景

Phase 36 で BENCH_MINIMAL に `small_policy_v7_snapshot()` の version check skip を追加し +0.71% を達成。
Phase 37 では Standard build に同様の最適化を適用するため、TLS cache を導入。

### 実施内容

**Phase 37: TLS cache box 実装**

1. `core/box/small_policy_snapshot_tls_box.h/.c` を作成
2. `small_policy_v7_snapshot()` に TLS cache 経由のパスを追加
3. ENV gate `HAKMEM_POLICY_SNAPSHOT_TLS` で制御（default ON）

**設計:**
- Fast path: TLS cache hit → cached pointer 返却
- Slow path: cache miss → init from env, update cache
- Rollback: `HAKMEM_POLICY_SNAPSHOT_TLS=0` で元の動作

### A/B Test 結果

**Baseline (TLS OFF):**
- Mean: 53,502,684 ops/s (10 runs)

**Phase 37 (TLS ON):**
- Mean: 53,465,435 ops/s (10 runs)

**Delta: -0.07%** ❌ NO-GO

### 原因分析

TLS cache が効果を出せなかった理由:

1. **Gate function overhead の再発**
   - `policy_snapshot_tls_enabled()` 自体が lazy-init pattern を使用
   - Phase 35-A で削除した問題と同じ overhead

2. **Non-inlined function call**
   - `small_policy_snapshot_tls_get()` は別翻訳単位のためインライン化されない
   - TLS 変数アクセス + 関数呼び出し overhead

3. **Original path は既に最適**
   - `g_small_policy_v7_version != g_policy_v7_version` は TLS 変数比較のみ
   - これ以上の最適化は BENCH_MINIMAL (compile-time constant) のみ

### 判定

**NO-GO ❌ (-0.07% < +1.0% threshold)**

**理由:**
- Standard build では gate function overhead を避けられない
- TLS cache の追加 overhead が version check 削減を相殺
- BENCH_MINIMAL が既に最適解（compile-time constant 化）

### 教訓

1. **Runtime gate は必ず overhead を持つ:** lazy-init pattern は避けられない
2. **Compile-time constant が唯一の解:** Standard build の最適化は限界がある
3. **BENCH_MINIMAL の正当性:** benchmark 専用 binary として最適化を分離するのが正解

### 次のステップ

- Phase 37 変更は NO-GO のためコードは残すがデフォルト OFF にすべき
- または削除検討（追加コードが無駄な overhead）
- 本線は Phase 35-A（BENCH_MINIMAL +4.39%）+ Phase 36（+0.71%）で固定

---

## Phase 38 完了（2025-12-16）— FAST/OBSERVE 運用確立

### 背景

Phase 37 で Standard build の最適化は限界（NO-GO -0.07%）と判明。
Standard を小手先で速くするより、**FAST/OBSERVE の運用を確立** する方が ROI が高い。

### 実施内容

**Step 1: スコアカード更新（SSOT）**
- `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` を更新
- Standard / FAST v2 / OBSERVE の mean/median を並記
- **mimalloc 比較は FAST build を正** と明記

**Step 2: Makefile ターゲット整備**
- `make perf_fast` — FAST build + 10-run benchmark
- `make perf_observe` — OBSERVE build + health check + 1-run perf
- `make perf_all` — 両方実行
- 手順をターゲット化（人間ミス防止）

**Step 3: FAST v3 候補特定**
- malloc path: `front_gate_unified_enabled()`, `alloc_dualhot_enabled()`
- free path: `g_bench_fast_front`, `g_v3_enabled`, `g_free_dispatch_ssot`
- stats: `alloc_gate_stats_enabled()`, `free_path_stats_enabled()`, `tiny_front_stats_enabled()`

### 運用ルール（確定）

1. **性能評価は FAST build で行う**（mimalloc 比較の正）
2. **Standard は安全基準**（gate overhead は許容、本線機能の互換性優先）
3. **OBSERVE はデバッグ用**（性能評価には使わない、診断出力あり）

### 現在の数値

| Build | Mean (M ops/s) | vs mimalloc |
|-------|----------------|-------------|
| **FAST v2** | 54.94 | **46.5%** |
| Standard | 53.50 | 45.3% |
| mimalloc | 118.18 | 100% |

### 次のステップ

**Phase 39: FAST v3** — 残りの default-ON gate を定数化
- 対象: malloc/free path の gate function
- 目標: FAST v3 で +0.5%+ を追加獲得

---

## Phase 30 完了（2025-12-16）

### 実施内容

**目的:** Phase 24-29 の学びを 4-step 標準手順として固定化し、Phase 31 候補を選定する。

**成果物:**
1. `docs/analysis/PHASE30_STANDARD_PROCEDURE.md` - 4-step 標準手順書
2. `docs/analysis/ATOMIC_AUDIT_FULL.txt` - 全 atomic 監査結果（412 atomics）
3. `docs/analysis/PHASE31_CANDIDATES_HOT.txt` - HOT path 候補抽出
4. `docs/analysis/PHASE31_CANDIDATES_WARM.txt` - WARM path 候補抽出
5. `docs/analysis/PHASE31_RECOMMENDED_CANDIDATES.md` - Phase 31 推奨候補（TOP 3）
6. `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` 更新（Phase 30 追記）

### 監査結果

**全 atomic 監査:**
- **Total atomics:** 412
- **TELEMETRY:** 104 (25%)
- **CORRECTNESS:** 24 (6%)
- **UNKNOWN:** 284 (69%, manual review needed)

**Path 分類:**
- **HOT path:** 16 atomics (5 TELEMETRY, 11 UNKNOWN)
- **WARM path:** 10 atomics (3 TELEMETRY, 7 UNKNOWN)
- **COLD path:** 386 atomics (remaining)

**NEW 候補（未コンパイルアウト）:**
- **HOT path:** 1 candidate (`g_tiny_free_trace`)
- **WARM path:** 3 candidates (`rel_logs`, `dbg_logs`, `g_p0_class_oob_log`)

### Step 0 実行確認結果

**HOT path:**
1. `g_tiny_free_trace` (HOT, TELEMETRY)
   - ✅ ENV gate なし
   - ✅ `hak_tiny_free()` で実行（毎回）
   - ✅ Execution verified
   - **Verdict:** **TOP PRIORITY for Phase 31**

**WARM path:**
1. `rel_logs` + `dbg_logs` (WARM, TELEMETRY)
   - ❌ ENV gated by `HAKMEM_TINY_WARM_LOG` (OFF by default)
   - ❌ 実行されない（Phase 29 pattern）
   - **Verdict:** SKIP

2. `g_p0_class_oob_log` (WARM, TELEMETRY)
   - ✅ ENV gate なし
   - ⚠️ Error path（out-of-bounds class index）
   - ❓ 実行頻度不明（要検証）
   - **Verdict:** LOW PRIORITY（Phase 32 候補）

### 4-Step Standard Procedure

**Phase 30 で確立された型:**

**Step 0: 実行確認（NEW - Phase 29 教訓）**
- ENV gate チェック（`rg "getenv.*FEATURE" core/`）
- 実行カウンタ確認（Mixed 10-run で > 0）
- perf/flamegraph 検証（オプション）
- **Decision:** ❌ 実行されない → SKIP

**Step 1: CORRECTNESS/TELEMETRY 分類（Phase 28 教訓）**
- 全使用箇所を追跡（`rg -n "g_variable" core/`）
- `if` 条件で使用 → CORRECTNESS（DO NOT TOUCH）
- `fprintf/fprintf` のみ → TELEMETRY（compile-out 候補）
- **Decision:** CORRECTNESS → DO NOT TOUCH

**Step 2: Compile-Out 実装（Phase 24-27 pattern）**
- `hakmem_build_flags.h` に gate 追加
- TELEMETRY atomic を `#if` で wrap
- Build-level compile-out（link-out 禁止）

**Step 3: A/B Test（build-level comparison）**
- Baseline (COMPILED=0): default build
- Compiled-in (COMPILED=1): research build
- **Verdict:** GO (+0.5%+), NEUTRAL (±0.5%), NO-GO (-0.5%+)

### 判定

**PROCEDURE COMPLETE** ✅

**理由:**
- 4-step procedure 確立（Phase 24-29 学習を体系化）
- Step 0 (実行確認) が Phase 29 空振りを防ぐ
- 全 atomic 監査完了（412 atomics）
- Phase 31 候補選定完了（TOP 1: `g_tiny_free_trace`）

### ドキュメント

- `docs/analysis/PHASE30_STANDARD_PROCEDURE.md` (標準手順書)
- `docs/analysis/ATOMIC_AUDIT_FULL.txt` (全 atomic 監査結果)
- `docs/analysis/PHASE31_RECOMMENDED_CANDIDATES.md` (Phase 31 候補 TOP 3)
- `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` (Phase 24-30 総括)

### 教訓

**空振り防止 3 原則:**
1. **Step 0 は必須ゲート**: ENV-gated コードは最初に弾く（Phase 29 教訓）
2. **カウンタ名 ≠ 用途**: Flow control か telemetry か全使用箇所で確認（Phase 28 教訓）
3. **HOT path 優先**: 実行頻度が性能影響を決める（Phase 24-27 教訓）

## 累積効果（Phase 24〜35-A）

| Phase | Target | Impact | Status |
|-------|--------|--------|--------|
| **24** | `g_tiny_class_stats_*` (5 atomics) | **+0.93%** | GO ✅ |
| **25** | `g_free_ss_enter` (1 atomic) | **+1.07%** | GO ✅ |
| **26** | Hot path diagnostics (5 atomics) | **-0.33%** | NEUTRAL ✅ |
| **27** | `g_unified_cache_*` (6 atomics) | **+0.74%** | GO ✅ |
| **28** | Background Spill Queue (8 atomics) | **N/A** | NO-OP ✅ |
| **29** | Pool Hotbox v2 Stats (12 atomics) | **0.00%** | NO-OP ✅ |
| **30** | Standard Procedure (412 atomic audit) | **N/A** | PROCEDURE ✅ |
| **31** | `g_tiny_free_trace` (1 atomic) | **-0.35%** | NEUTRAL ✅ |
| **32** | `g_hak_tiny_free_calls` (1 atomic) | **-0.46%** | NEUTRAL ✅ |
| **34** | Batch Prune (atomic 一括) | **-0.10%** | NEUTRAL ✅ |
| **35-A** | BENCH_MINIMAL gate prune | **+4.39%** | **GO ✅** |
| **合計** | **19 atomics removed + gate prune** | **+7.13%** | **✅** |

**Key Insight:** 標準手順が次の Phase の成功確率を上げる。
- Step 0 (実行確認) で ENV-gated code を弾く → Phase 29 空振りを防止
- Step 1 (分類) で CORRECTNESS を弾く → Phase 28 誤判定を防止
- HOT path 優先 → Phase 24-27 成功パターン（+0.5~1.0%）
- **NEW:** NEUTRAL verdict でも code cleanliness で採用可 → Phase 26/31 パターン

## Phase 32: g_hak_tiny_free_calls compile-out 完了（2025-12-16）

### 実施内容

**目的:** `hak_tiny_free()` で毎回実行される diagnostic counter atomic を compile-out（default）して固定税を削る。

**成果物:**
1. `docs/analysis/PHASE32_TINY_FREE_CALLS_ATOMIC_PRUNE_RESULTS.md` - A/B test results + NEUTRAL verdict
2. `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` 更新（Phase 32 追記）
3. `CURRENT_TASK.md` 更新（Phase 32 完了 + Phase 33 候補提示）

### A/B Test 結果

**Baseline (COMPILED=0, counter compiled-out):**
- Mean: 52.94 M ops/s
- Median: 53.22 M ops/s

**Compiled-in (COMPILED=1, counter active):**
- Mean: 53.28 M ops/s
- Median: 53.46 M ops/s

**Difference:**
- Mean: -0.63% (Baseline SLOWER)
- Median: -0.46% (Baseline SLOWER)
- **Verdict:** **NEUTRAL** (±0.5% 範囲内、しかも compiled-in が faster - 反転現象)

### 判定

**NEUTRAL → Code Cleanliness で採用** ✅

**理由:**
1. **Performance:** Mean -0.63%, Median -0.46% → 測定ノイズ範囲（しかも compiled-in が faster - 予想外）
2. **Phase 31 precedent:** -0.35% NEUTRAL → code cleanliness で採用
3. **Phase 32 同型:** -0.46% NEUTRAL → 同じ判断基準を適用
4. **Code cleanliness benefits:**
   - HOT path (`hak_tiny_free()` entry, Phase 31 の 9 行下) から unused TELEMETRY atomic 削除
   - 複雑さ削減（diagnostic counter のみ、flow control なし）
   - Research flexibility 維持（`COMPILED=1` で復活可）
5. **Unexpected finding:** Atomic counter compiled-in は faster → code alignment effects の可能性（atomic overhead ではない）

**Key Finding:** Diagnostic counter has negligible impact on modern CPUs
- Phase 25 (`g_free_ss_enter`): +1.07% GO (always-increment stats)
- Phase 31 (`g_tiny_free_trace`): -0.35% NEUTRAL (rate-limited to 128 calls)
- Phase 32 (`g_hak_tiny_free_calls`): -0.46% NEUTRAL (unconditional counter)
- **Pattern:** Phase 31+32 (same function, 9 lines apart) both NEUTRAL → atomic overhead is negligible

### ドキュメント

- `docs/analysis/PHASE32_TINY_FREE_CALLS_ATOMIC_PRUNE_RESULTS.md` (完全な A/B test 結果)
- `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` (Phase 24-32 総括)
- `CURRENT_TASK.md` (Phase 32 完了 + Phase 33 候補)

### 教訓

**Phase 32 から学んだこと:**
1. **Code alignment matters:** Compiled-in が faster → atomic overhead ではなく code layout effects
2. **NEUTRAL is still valid:** Phase 26/31/32 precedent - code cleanliness で採用
3. **Not all HOT atomics matter:** Phase 31+32 (same function) both NEUTRAL → 固定税は negligible
4. **Cumulative gain is stable:** +2.74% (Phase 24+25+27 GO が大部分、Phase 31+32 は cleanliness のみ)

## Phase 31: g_tiny_free_trace compile-out 完了（2025-12-16）

### 実施内容

**目的:** `hak_tiny_free()` 先頭の trace-rate-limit atomic を compile-out（default）して固定税を削る。

**成果物:**
1. `docs/analysis/PHASE31_TINY_FREE_TRACE_ATOMIC_PRUNE_RESULTS.md` - A/B test results + NEUTRAL verdict
2. `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` 更新（Phase 31 追記）
3. `CURRENT_TASK.md` 更新（Phase 31 完了 + Phase 32 候補提示）

### A/B Test 結果

**Baseline (COMPILED=0, trace compiled-out):**
- Mean: 53.64 M ops/s
- Median: 53.80 M ops/s

**Compiled-in (COMPILED=1, trace active):**
- Mean: 53.83 M ops/s
- Median: 53.70 M ops/s

**Difference:**
- Mean: -0.35% (Baseline SLOWER)
- Median: +0.19% (Baseline FASTER)
- **Verdict:** **NEUTRAL** (±0.5% 範囲内)

### 判定

**NEUTRAL → Code Cleanliness で採用** ✅

**理由:**
1. **Performance:** Mean -0.35%, Median +0.19% → 測定ノイズ範囲（conflicting signals）
2. **Phase 26 precedent:** -0.33% NEUTRAL → code cleanliness で採用
3. **Phase 31 同型:** -0.35% NEUTRAL → 同じ判断基準を適用
4. **Code cleanliness benefits:**
   - HOT path (`hak_tiny_free()` entry) から unused TELEMETRY atomic 削除
   - 複雑さ削減（trace macro のみ、flow control なし）
   - Research flexibility 維持（`COMPILED=1` で復活可）

**Key Finding:** Not all HOT path atomics have measurable overhead
- Phase 25 (`g_free_ss_enter`): +1.07% GO (always-increment stats)
- Phase 31 (`g_tiny_free_trace`): NEUTRAL (rate-limited to 128 calls)
- **Hypothesis:** Rate-limiting or compiler optimization may eliminate overhead

### ドキュメント

- `docs/analysis/PHASE31_TINY_FREE_TRACE_ATOMIC_PRUNE_RESULTS.md` (完全な A/B test 結果)
- `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md` (Phase 24-31 総括)
- `CURRENT_TASK.md` (Phase 31 完了 + Phase 32 候補)

### 教訓

**Phase 31 から学んだこと:**
1. **HOT path ≠ guaranteed win:** Even high-frequency atomics may have zero overhead if optimized
2. **NEUTRAL is valid:** Code cleanliness justifies compile-out even without performance gain (Phase 26/31 precedent)
3. **Step 0 (execution verification) works:** Prevented Phase 29-style no-op (confirmed always active)
4. **Standard procedure validated:** Phase 30 4-step procedure successfully guided Phase 31

## 次の指示（Phase 33 実施）

**Phase 32 完了:** NEUTRAL verdict、code cleanliness で採用 → Phase 33 実施へ

### Phase 33 推奨候補: `tiny_debug_ring_record()` (HOT path, **STEP 0 VERIFICATION REQUIRED**) ⚠️

**Location:** `core/hakmem_tiny_free.inc:340` (3 lines after Phase 32 target)

**Code Context:**
```c
void hak_tiny_free(void* ptr) {
#if HAKMEM_TINY_FREE_TRACE_COMPILED
    // Phase 31 target (now compiled-out)
#endif
#if HAKMEM_TINY_FREE_CALLS_COMPILED
    // Phase 32 target (now compiled-out)
#endif
    if (!ptr || !g_tiny_initialized) return;

    hak_tiny_stats_poll();
    tiny_debug_ring_record(TINY_RING_EVENT_FREE_ENTER, 0, ptr, 0);  // ← Phase 33 target
    // ... rest of function ...
}
```

**Classification:**
- **Class:** TELEMETRY (debug ring buffer, event logging)
- **Path:** HOT (every tiny free call, after null check)
- **Usage:** Event logging to ring buffer
- **ENV Gate:** ⚠️ **UNKNOWN - REQUIRES STEP 0 VERIFICATION**

**⚠️ CRITICAL: Step 0 Verification Required (Phase 30 lesson)**

**Phase 32 完了後、Phase 33 実施前に必須:**

```bash
# Check if debug ring is ENV-gated or always-on
rg "getenv.*DEBUG_RING" core/
rg "HAKMEM.*DEBUG.*RING" core/
rg "tiny_debug_ring_record" core/ -A 5 -B 5
```

**Verification criteria:**
1. ✅ **Proceed if:** No ENV gate, always-on by default
2. ❌ **SKIP if:** ENV-gated (like Phase 29 Pool v2)
3. ❓ **Verify if:** Conditional gate inside `tiny_debug_ring_record()` implementation

**Expected Impact:**
- **If always-on:** +0.3% to +1.0% (ring buffer writes may be expensive)
- **If ENV-gated (OFF by default):** 0.00% (Phase 29 NO-OP pattern)

**Priority:** **HIGHEST** (same HOT path as Phase 31+32, same function, 3 lines below Phase 32)

**⚠️ DO NOT PROCEED WITHOUT STEP 0 VERIFICATION ⚠️**

**Phase 30 教訓適用:**
- Phase 29 で ENV-gated code (Pool v2) を空振り → Step 0 必須化
- Phase 30 で Step 0 を標準手順に追加
- Phase 33 は debug ring → ENV gate の可能性高い → **実行確認必須**

**Implementation Plan (AFTER Step 0 verification):**

**If always-on (Step 0 PASS):**

**Step 1: 分類**
- Check `tiny_debug_ring_record()` implementation
- Verify TELEMETRY (no flow control)
- Check for atomics inside ring buffer writes

**Step 2: Compile-Out 実装**
- Add `HAKMEM_TINY_DEBUG_RING_COMPILED` to `hakmem_build_flags.h`
- Wrap `tiny_debug_ring_record()` calls with `#if`

**Step 3: A/B Test**
- Baseline (COMPILED=0): ring buffer compiled-out
- Compiled-in (COMPILED=1): ring buffer active
- Expected: +0.3% to +1.0% if expensive writes

**If ENV-gated (Step 0 FAIL):**
- ❌ SKIP Phase 33 (Phase 29 NO-OP pattern)
- Move to next candidate

### Alternative Candidates (if Phase 33 is ENV-gated or NEUTRAL)

**#4: `g_p0_class_oob_log` (WARM path, error logging)**
- ❓ Execution uncertain (error path)
- Expected: ±0.0% to +0.2%
- Action: Verify execution first

**#5-#N: Manual review of UNKNOWN atomics (284 candidates)**
- Many may be misclassified by naming heuristics
- Requires deeper code inspection
- Lower priority

**Note:** Phase 31+32 both NEUTRAL → HOT path atomic prune 効果は限定的。Phase 24+25+27 (GO phases) が cumulative gain の大部分。今後は他の最適化領域（inlining, branch optimization, SIMD）へ移行を検討。

## 参考

- **Standard Procedure:** `docs/analysis/PHASE30_STANDARD_PROCEDURE.md`
- **Phase 31 Results:** `docs/analysis/PHASE31_TINY_FREE_TRACE_ATOMIC_PRUNE_RESULTS.md`
- **Phase 32 Results:** `docs/analysis/PHASE32_TINY_FREE_CALLS_ATOMIC_PRUNE_RESULTS.md`
- **Cumulative Summary:** `docs/analysis/ATOMIC_PRUNE_CUMULATIVE_SUMMARY.md`
- **mimalloc Gap Analysis:** `docs/roadmap/OPTIMIZATION_ROADMAP.md`
- **Box Theory:** Phase 6-1.7+ の Box Refactor パターン
- **Phase 24-27 Pattern:** `core/box/tiny_class_stats_box.h`, `core/hakmem_build_flags.h`
- **Phase 26/31/32 NEUTRAL Precedent:** Code cleanliness adoption without performance win

## タスク完了条件

### Phase 30 完了済み条件（2025-12-16）:
1. ✅ `PHASE30_STANDARD_PROCEDURE.md` 作成（4-step procedure）
2. ✅ 全 atomic 監査実行（412 atomics, audit_atomics.sh）
3. ✅ HOT/WARM path TELEMETRY 候補抽出
4. ✅ Step 0 実行確認（全候補）
5. ✅ `PHASE31_RECOMMENDED_CANDIDATES.md` 作成（TOP 3 prioritized）
6. ✅ Cumulative summary 更新（Phase 24-30）
7. ✅ CURRENT_TASK.md 更新（Phase 31 候補提示）

### Phase 31 完了条件（2025-12-16）:
1. ✅ 候補選定完了（`g_tiny_free_trace`, HOT path）
2. ✅ Step 0 実行確認完了（ENV gate なし、実行確認済み）
3. ✅ Step 1 分類完了（Pure TELEMETRY、CORRECTNESS なし）
4. ✅ Step 2 実装（BuildFlags + `#if` wrap）
5. ✅ Step 3 A/B test（Baseline vs Compiled-in）
6. ✅ 結果ドキュメント作成（PHASE31_RESULTS.md）
7. ✅ NEUTRAL verdict → code cleanliness で採用

### Phase 32 完了条件（2025-12-16）:
1. ✅ 候補選定完了（`g_hak_tiny_free_calls`, HOT path, same function as Phase 31）
2. ✅ Step 0 実行確認完了（Phase 31 と同じ関数、ENV gate なし）
3. ✅ Step 1 分類完了（Pure TELEMETRY、CORRECTNESS なし）
4. ✅ Step 2 実装（BuildFlags + `#if` wrap）
5. ✅ Step 3 A/B test（Baseline vs Compiled-in）
6. ✅ 結果ドキュメント作成（PHASE32_RESULTS.md）
7. ✅ NEUTRAL verdict → code cleanliness で採用

### Phase 33 開始前の前提条件:
1. ✅ 候補選定完了（`tiny_debug_ring_record()`, HOT path, 3 lines after Phase 32）
2. ⚠️ **Step 0 実行確認必須**（ENV gate check: `rg "getenv.*DEBUG_RING" core/`）
3. ⏳ Step 1 分類（TELEMETRY/CORRECTNESS 判定） - AFTER Step 0
4. ⏳ Step 2 実装（BuildFlags + `#if` wrap） - AFTER Step 0
5. ⏳ Step 3 A/B test（Baseline vs Compiled-in） - AFTER Step 0
6. ⏳ 結果ドキュメント作成（PHASE33_RESULTS.md） - AFTER Step 0

---

**Last Updated:** 2025-12-16
**Current Phase:** Phase 36 Complete (BENCH_MINIMAL v2 - policy_v7_snapshot optimization)
**Status:**
- ✅ FAST build v2 (`bench_random_mixed_hakmem_minimal`) - 性能計測用正規ターゲット
- ✅ OBSERVE build (`bench_random_mixed_hakmem_observe`) - 挙動観測用ターゲット
- ⏳ Option C (本線 default=1) - 運用方針確立後に検討

**Phase 36 Results:**
- FAST v1 → FAST v2: +0.71% (GO)
- 追加最適化: `small_policy_v7_snapshot()` version check スキップ、learner gates 固定 OFF

**Cumulative Progress:** +7.84% potential (atomic prune +2.74% + gate prune Phase 35-A +4.39% + Phase 36 +0.71%)