# CURRENT TASK - Critical Bugs Fixed

**Last Updated**: 2025-11-29
**Branch**: `master` @ 6d40dc741
**Scope**: Header Corruption + Segfault 根治完了 - 完全安定化達成

---

## 🎉 2025-11-29 UPDATE: CRITICAL BUGS RESOLVED

### ✅ 完了した修正

#### 1. Header Corruption Bug (Class 1) - **根治完了**
- **症状**: `[TLS_SLL_HDR_RESET] cls=1 got=0x00 expect=0xa1`
- **原因**: freelist → TLS SLL の2パスで header 未復元
- **修正**: 両パスに header restoration 追加
- **結果**: 20-thread Larson で header corruption **完全消滅** ✅

**Commits:**
- `3c6c76cb1` - box_carve_and_push_with_freelist() fix
- `a94344c1a` - tiny_drain_freelist_to_sll_once() fix

#### 2. Segmentation Fault Bug - **根治完了**
- **症状**: larson_hakmem が intermittent に SEGV (~50% 確率)
- **原因**: superslab_allocate() の implicit int declaration → pointer corruption via sign extension
- **修正**: 2ファイルに `#include "box/ss_allocation_box.h"` 追加
- **結果**: larson_hakmem が完全安定動作 ✅

**Commit:**
- `6d40dc741` - Add missing superslab_allocate() declaration

### 🔬 Task Agent の貢献
- Header corruption: 全 freelist paths を網羅的調査、dead code path まで発見
- Segfault: gdb + coredump で Assembly レベル解析、sign extension メカニズムを特定

### 📊 現在の安定性
| Test | Status |
|------|--------|
| Larson 1T | ✅ 安定動作 (51.95M ops/s) |
| Larson 4T | ✅ 安定動作 (header validation 有効) |
| Larson 20T | ✅ Header corruption 0 errors |
| Random Mixed | ✅ 安定動作 (66.82M ops/s) |
| SuperSlab expansion | ✅ Segfault 消滅 |

---

## 📋 Stable Master Established (2025-11-26)

**Branch**: `master` (formerly `larson-master-rebuild`)
**Scope**: 安定版 master 確立完了 - Larson 動作 + 67M ops/s

---

## 🎯 現状サマリ

### ✅ 新 master 性能（安定版）
| Benchmark | Performance | Status |
|-----------|-------------|--------|
| Larson 1T | **51.95M ops/s** | ✅ 安定動作 (0% crash) |
| Random Mixed 256B | **66.82M ops/s** | ✅ 安定動作 |

**Branch**: `master` @ d26dd092b
**Architecture**: E1-CORRECT (C0,C7 offset=0; C1-C6 offset=1)

### 📚 旧 master 保存（参考用）
- **Branch**: `master-80M-unstable` @ 328a6b722
- Random Mixed: ~80M ops/s
- Larson: **100% クラッシュ** (Step 2.5 バグ)
- Architecture: UNIFIED-HEADER (全クラス offset=1)
- **80M 達成経路**: `PERFORMANCE_HISTORY_62M_TO_80M.md` 参照

---

## 📋 作業計画

### Phase 0: 安定ベースライン確立 ✅ DONE
- [x] `larson-fix` ブランチから `larson-master-rebuild` 作成
- [x] Larson 動作確認 (51M ops/s)
- [x] Random Mixed 動作確認 (62M ops/s)

### Phase 1: クリーンアップ & 安定化 ✅ DONE
**目標**: 安定状態でコードベースを整理

#### 1.1 Cherry-pick 済み（7コミット）
- [x] `9793f17d6` レガシーコード削除 (-1,159 LOC)
- [x] `cc0104c4e` テストファイル削除 (-1,750 LOC)
- [x] `416930eb6` バックアップファイル削除 (-1,072 KB)
- [x] `225b6fcc7` 死コード削除: UltraHot, RingCache等 (-1,844 LOC)
- [x] `2c99afa49` 学習システムバグドキュメント
- [x] `328a6b722` Larsonバグ分析更新
- [x] `0143e0fed` CONFIGURATION.md 追加

#### 1.2 追加最適化
- [x] `a2e65716b` tiny_get_max_size inline化 (+2M ops/s期待値)
- [x] `d35504163` Superslab Min-Keep ポート（後にリバート）
- [x] `bea839add` Min-Keep リバート（Larson 安定化）
- [x] `d26dd092b` Performance History ドキュメント作成

#### 1.3 master 確立
- [x] 旧 master を `master-80M-unstable` にバックアップ
- [x] master ブランチを安定版 (d26dd092b) に更新
- [x] Larson 0% crash 確認 (51.95M ops/s)
- [x] Random Mixed 67M ops/s 確認

### Phase 2: 性能最適化ポート 📊 PENDING
**目標**: 62M → 80M+ ops/s 回復

#### 2.1 簡単なチューニング（独立・低リスク）
- [ ] `e81fe783d` tiny_get_max_size inline化 (+2M)
- [ ] `04a60c316` Superslab/SharedPool チューニング (+1M)
- [ ] `392d29018` Unified Cache容量チューニング (+1M)
- [ ] `dcd89ee88` Stage 1 lock-free (+0.3M)

#### 2.2 本丸（UNIFIED-HEADER）
- [ ] `472b6a60b` Phase UNIFIED-HEADER (+17%, C7ヘッダ統一)
- [ ] `d26519f67` UNIFIED-HEADERバグ修正 (+15-41%)
- [ ] `165c33bc2` Larsonフォールバック修正（必要なら）

#### 2.3 スキップ対象
- ❌ `03d321f6b` Phase 27 Ultra-Inline → **-10~15%回帰**
- ❌ Step 2.5関連コミット → **Larsonクラッシュの原因**

### Phase 3: 検証 & マージ 🔀 PENDING
- [ ] Larson 10回平均ベンチマーク
- [ ] Random Mixed 10回平均ベンチマーク
- [ ] master ブランチ更新

---

## 🔍 根本原因分析

### Larson クラッシュの原因
**First Bad Commit**: `19c1abfe7` "Fix Unified Cache TLS SLL bypass"

Step 2.5 が TLS_SLL_PUSH_DUP を「修正」するために追加されたが：
1. TLS_SLL_PUSH_DUP は実際には発生しない（ベースで10M回テスト済み）
2. Step 2.5 がマルチスレッド環境で cross-thread ownership 問題を引き起こす
3. 結論：**不要な「修正」が Larson を壊した**

### 80M 達成の主要因
| コミット | 内容 | 改善幅 |
|---------|------|--------|
| `472b6a60b` | UNIFIED-HEADER (C7統一) | **+17%** |
| `d26519f67` | UH バグ修正 | +15-41% |
| その他チューニング | inline, policy等 | +4-5M |

---

## 📁 関連ファイル

### 修正対象
- `core/front/tiny_unified_cache.c` - Step 2.5 なしのまま維持
- `core/tiny_free_fast_v2.inc.h` - LARSON_FIX 関連
- `core/box/ptr_conversion_box.h` - UNIFIED-HEADER で変更予定

### ドキュメント
- `LEARNING_SYSTEM_BUGS_P0.md` - 学習システムバグ記録
- `CONFIGURATION.md` - ENV変数リファレンス
- `PROFILES.md` - 性能プロファイル

---

## ✅ 完了マイルストーン

1. **Larson 安定化** - 51M ops/s で動作 ✅
2. **Cherry-pick Phase 1** - 7コミット完了 ✅
3. **ベースライン確立** - 62M/51M で安定 ✅

---

## Phase FREE-LEGACY-OPT シリーズ（2025-12-11）

### Phase FREE-LEGACY-OPT-4-1: Legacy per-class 分析 ✅ 完了

**目的**: Legacy fallback 49.2% の内訳を per-class で分析

**測定結果（Mixed 16-1024B）**:
- **C6 (513-1024B)**: 51.4% (137,319 / 266,942 Legacy calls)
- C5 (257-512B): 25.8%
- C4 (129-256B): 13.0%
- C3 (65-128B): 6.5%
- C2 (33-64B): 3.3%
- C0/C1/C7: 0.0%

**最大ターゲット**: C6 が Legacy の過半数を占める

**詳細**: `docs/analysis/FREE_LEGACY_PATH_ANALYSIS.md` 参照

### Phase FREE-LEGACY-OPT-4-2: C6_ULTRA_FREE_BOX 実装（進行中）

**目的**: C6 の free だけを C7 ULTRA 風 TLS キャッシュで受け、Legacy fallback を半減

**実装範囲**:
- C6 専用・free 専用（alloc は既存ルートのまま）
- TLS に `c6_freelist[32]` + `c6_count` + segment range check
- ENV: `HAKMEM_TINY_C6_ULTRA_FREE_ENABLED=0`（研究箱、デフォルト OFF）

**期待効果**:
- Legacy fallback: 49.2% → 24-27%（C6 分を削減）
- Mixed throughput: +5-8% 改善（44.8M → 47-48M ops/s）

---

## 🎯 次のアクション

### 現時点での選択肢

1. **Option A: 現状維持（推奨）**
   - master @ 67M ops/s (Larson 安定)
   - 80M の知見は `PERFORMANCE_HISTORY_62M_TO_80M.md` と `master-80M-unstable` に保存済み
   - Phase 2 (性能最適化) は将来の作業として保留

2. **Option B: UNIFIED-HEADER ポート（高難度）**
   - 80M 達成の主要因（+17% + +15-41%）
   - E1-CORRECT との互換性問題あり
   - 大規模な書き換えが必要
   - 詳細: `PERFORMANCE_HISTORY_62M_TO_80M.md` Section "Option 3"

3. **Option C: Step 2.5 Revert（失敗済み）**
   - 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: 再計測（必須）