Files
hakmem/docs/design/REFACTOR_QUICK_START.md
Moe Charm (CI) 67fb15f35f Wrap debug fprintf in !HAKMEM_BUILD_RELEASE guards (Release build optimization)
## Changes

### 1. core/page_arena.c
- Removed init failure message (lines 25-27) - error is handled by returning early
- All other fprintf statements already wrapped in existing #if !HAKMEM_BUILD_RELEASE blocks

### 2. core/hakmem.c
- Wrapped SIGSEGV handler init message (line 72)
- CRITICAL: Kept SIGSEGV/SIGBUS/SIGABRT error messages (lines 62-64) - production needs crash logs

### 3. core/hakmem_shared_pool.c
- Wrapped all debug fprintf statements in #if !HAKMEM_BUILD_RELEASE:
  - Node pool exhaustion warning (line 252)
  - SP_META_CAPACITY_ERROR warning (line 421)
  - SP_FIX_GEOMETRY debug logging (line 745)
  - SP_ACQUIRE_STAGE0.5_EMPTY debug logging (line 865)
  - SP_ACQUIRE_STAGE0_L0 debug logging (line 803)
  - SP_ACQUIRE_STAGE1_LOCKFREE debug logging (line 922)
  - SP_ACQUIRE_STAGE2_LOCKFREE debug logging (line 996)
  - SP_ACQUIRE_STAGE3 debug logging (line 1116)
  - SP_SLOT_RELEASE debug logging (line 1245)
  - SP_SLOT_FREELIST_LOCKFREE debug logging (line 1305)
  - SP_SLOT_COMPLETELY_EMPTY debug logging (line 1316)
- Fixed lock_stats_init() for release builds (lines 60-65) - ensure g_lock_stats_enabled is initialized

## Performance Validation

Before: 51M ops/s (with debug fprintf overhead)
After:  49.1M ops/s (consistent performance, fprintf removed from hot paths)

## Build & Test

```bash
./build.sh larson_hakmem
./out/release/larson_hakmem 1 5 1 1000 100 10000 42
# Result: 49.1M ops/s
```

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-26 13:14:18 +09:00

315 lines
7.7 KiB
Markdown

# HAKMEM Tiny リファクタリング - クイックスタートガイド
## 本ドキュメントについて
3つの計画書を読む時間がない場合、このガイドで必要な情報をすべて把握できます。
---
## 1分で理解
**目標**: hakmem_tiny_free.inc (1470行) を 500行以下に分割
**効果**:
- Fast path: 20+ instructions → 3-4 instructions (-80%)
- Throughput: +10-25%
- Code review: 3h → 30min (-90%)
**期間**: 6週間 (20時間コーディング)
---
## 5分で理解
### 現状の問題
```
hakmem_tiny_free.inc (1470行)
├─ Free パス (400行)
├─ SuperSlab Alloc (400行)
├─ SuperSlab Free (400行)
├─ Query (commented-out, 100行)
└─ Shutdown (30行)
問題: 単一ファイルに4つの責務が混在
→ 複雑度が高い, バグが多発, 保守が困難
```
### 解決策
```
9つのBoxに分割 (各500行以下):
Box 1: tiny_atomic.h (80行) - Atomic ops
Box 2: tiny_remote_queue.inc.h (300行) - Remote queue
Box 3: hakmem_tiny_superslab.{c,h} (810行, 既存)
Box 4: tiny_adopt.inc.h (300行) - Adopt logic
Box 5: tiny_alloc_fast.inc.h (250行) - Fast path (3-4 cmd)
Box 6: tiny_free_fast.inc.h (200行) - Same-thread free
Box 7: Statistics & Query (existing)
Box 8: Lifecycle & Init (split into 5 files)
Box 9: Intel-specific (split into 3 files)
各Boxが単一責務 → テスト可能 → 保守しやすい
```
---
## 15分で全体理解
### 実装計画 (6週間)
| Week | Focus | Files | Lines |
|------|-------|-------|-------|
| 1 | Fast Path | tiny_atomic.h, tiny_alloc_fast.inc.h, tiny_free_fast.inc.h | 530 |
| 2 | Remote/Own | tiny_remote_queue.inc.h, tiny_owner.inc.h | 420 |
| 3 | Publish/Adopt | tiny_adopt.inc.h, mailbox split | 430 |
| 4 | Alloc/Free Slow | tiny_alloc_slow.inc.h, tiny_free_remote.inc.h, tiny_free_guard.inc.h | 720 |
| 5 | Lifecycle/Intel | tiny_init_*.inc.h, tiny_lifecycle_*.inc.h, tiny_intel_*.inc.h | 1070 |
| 6 | Test/Bench | Unit tests, Integration tests, Performance validation | - |
### 期待効果
| Metric | Before | After | Improvement |
|--------|--------|-------|-------------|
| Fast path cmd | 20+ | 3-4 | -80% |
| Max file size | 1470行 | 500行 | -66% |
| Code review | 3h | 30min | -90% |
| Throughput | 52 M/s | 58-65 M/s | +10-25% |
---
## 30分で準備完了
### Step 1: 3つのドキュメントを確認
```bash
ls -lh REFACTOR_*.md
# 1. REFACTOR_SUMMARY.md (13KB) を読む (15分)
# 2. REFACTOR_PLAN.md (22KB) で詳細確認 (30分)
# 3. REFACTOR_IMPLEMENTATION_GUIDE.md (17KB) で実装例確認 (20分)
```
### Step 2: 現状ベースラインを記録
```bash
# Fast path latency を測定
./larson_hakmem 16 1 1000 1000 0 > baseline.txt
# Assembly を確認
gcc -S -O3 core/hakmem_tiny.c
# Include 依存関係を可視化
cd core && \
grep -h "^#include" *.c *.h | sort | uniq | wc -l
# Expected: 100+ includes
```
### Step 3: Week 1 の計画を立てる
```bash
# REFACTOR_IMPLEMENTATION_GUIDE.md Phase 1.1-1.4 をプリントアウト
wc -l core/tiny_atomic.h core/tiny_alloc_fast.inc.h core/tiny_free_fast.inc.h
# Expected: 80 + 250 + 200 = 530行
# テストテンプレートを確認
# REFACTOR_IMPLEMENTATION_GUIDE.md の Testing Framework セクション
```
---
## よくある質問
### Q1: 実装の優先順位は?
**A**: 箱理論に基づく依存関係順:
1. **Box 1 (tiny_atomic.h)** - 最下層、他すべてが依存
2. **Box 2 (Remote/Ownership)** - リモート通信の基盤
3. **Box 3 (SuperSlab)** - 中核アロケータ (既存)
4. **Box 4 (Publish/Adopt)** - マルチスレッド連携
5. **Box 5-6 (Alloc/Free)** - メインパス
6. **Box 7-9** - 周辺・最適化
詳細: REFACTOR_PLAN.md Phase 3
---
### Q2: パフォーマンス回帰のリスクは?
**A**: 4段階の検証で排除:
1. **Assembly review** - 命令数を確認 (Week 1)
2. **Unit tests** - Box ごとのテスト (Week 1-5)
3. **Integration tests** - End-to-end テスト (Week 5-6)
4. **Larson benchmark** - 全体パフォーマンス (Week 6)
詳細: REFACTOR_IMPLEMENTATION_GUIDE.md の Performance Validation
---
### Q3: 既存コードとの互換性は?
**A**: 完全に保つ:
- 古い .inc ファイルは削除しない
- Feature flags で新旧を切り替え可能 (HAKMEM_TINY_NEW_FAST_PATH=0)
- Rollback plan が完備されている
詳細: REFACTOR_IMPLEMENTATION_GUIDE.md の Rollback Plan
---
### Q4: 循環依存はどう防ぐ?
**A**: 層状の DAG (Directed Acyclic Graph) 設計:
```
Layer 0 (tiny_atomic.h)
Layer 1 (tiny_remote_queue.inc.h)
Layer 2-3 (SuperSlab, Publish/Adopt)
Layer 4-6 (Alloc/Free)
Layer 7-9 (Stats, Lifecycle, Intel)
各層は上位層にのみ依存 → 循環依存なし
```
詳細: REFACTOR_PLAN.md Phase 5
---
### Q5: テストはどこまで書く?
**A**: 3段階:
| Level | Coverage | Time |
|-------|----------|------|
| Unit | 個々の関数テスト | 30min/func |
| Integration | パス全体テスト | 1h/path |
| Performance | Larson benchmark | 2h |
例: REFACTOR_IMPLEMENTATION_GUIDE.md の Testing Framework
---
## 実装チェックリスト (印刷向け)
### Week 1: Fast Path
```
□ tiny_atomic.h を作成
□ macros: load, store, cas, exchange
□ unit tests を書く
□ コンパイル確認
□ tiny_alloc_fast.inc.h を作成
□ tiny_alloc_fast_pop() (3-4 cmd)
□ tiny_alloc_fast_push()
□ unit tests
□ Cache hit rate を測定
□ tiny_free_fast.inc.h を作成
□ tiny_free_fast() (ownership check)
□ Same-thread free パス
□ unit tests
□ hakmem_tiny_free.inc を refactor
□ Fast path を抽出 (1470 → 800行)
□ コンパイル確認
□ Integration tests 実行
□ Larson benchmark で +10% を目指す
```
### Week 2-6: その他の Box
- REFACTOR_PLAN.md Phase 3 を参照
- REFACTOR_IMPLEMENTATION_GUIDE.md で各 Box の実装例を確認
- 毎週 Benchmark を実行して進捗を記録
---
## デバッグのコツ
### Include order エラーが出た場合
```bash
# Include の依存関係を確認
grep "^#include" core/tiny_*.h | grep -v "<" | head -20
# Compilation order を確認
gcc -c -E core/hakmem_tiny.c 2>&1 | grep -A5 "error:"
# 解決策: REFACTOR_PLAN.md Phase 5 の include order を参照
```
### パフォーマンスが低下した場合
```bash
# Assembly を確認
gcc -S -O3 core/hakmem_tiny.c
grep -A10 "tiny_alloc_fast_pop:" core/hakmem_tiny.s | wc -l
# Expected: <= 8 instructions
# Profiling
perf record -g ./larson_hakmem 16 1 1000 1000 0
perf report
# Hot spot を特定して最適化
```
### テストが失敗した場合
```bash
# Unit test を詳細表示
./test_tiny_atomic -v
# 特定の Box をテスト
gcc -I./core tests/test_tiny_atomic.c -lhakmem -o /tmp/test
/tmp/test
# 既知の問題がないか REFACTOR_PLAN.md Phase 7 (Risk) を確認
```
---
## 重要なリマインダー
1. **Baseline を記録**: Week 1 開始前に必ず larson benchmark を実行
2. **毎週ベンチマーク**: パフォーマンス回帰を早期発見
3. **テスト優先**: コード量より テストカバレッジを重視
4. **Rollback plan**: 必ず理解して実装開始
5. **ドキュメント更新**: 各 Box 完成時に doc を更新
---
## 次のステップ
```bash
# Step 1: REFACTOR_SUMMARY.md を読む
less REFACTOR_SUMMARY.md
# Step 2: REFACTOR_PLAN.md で詳細確認
less REFACTOR_PLAN.md
# Step 3: Baseline ベンチマークを実行
make clean && make
./larson_hakmem 16 1 1000 1000 0 > baseline.txt
# Step 4: Week 1 の実装を開始
cd core
# ... tiny_atomic.h を作成
```
---
## 連絡先・質問
- **戦略/分析**: REFACTOR_PLAN.md
- **実装例**: REFACTOR_IMPLEMENTATION_GUIDE.md
- **期待効果**: REFACTOR_SUMMARY.md
**Happy Refactoring!**