hakmem/CURRENT_TASK.md

# CURRENT TASK – Performance Optimization Status

**Last Updated**: 2025-11-25
**Scope**: Random Mixed 16-1024B / Arena Allocator / Architecture Limit Analysis

---

## 🎯 現状サマリ

### ✅ Arena Allocator 実装完了 - mmap 95% 削減達成

| Metric | Before | After | Improvement |
|--------|--------|-------|-------------|
| mmap syscalls | 401 | 32 | -92% |
| munmap syscalls | 378 | 3 | -99% |
| Performance (10M) | ~60M ops/s | **68-70M ops/s** | +15% |

### 現在の性能比較 (10M iterations)
```
System malloc: 93M ops/s (baseline)
HAKMEM:        68-70M ops/s (73-76% of system malloc)
Gap:           ~25% (構造的オーバーヘッド)
```

---

## 🔬 Phase 27 調査結果: アーキテクチャ限界の確認

### 試した最適化（すべて失敗）
| 最適化案 | 結果 | 効果 |
|---------|------|------|
| C5 TLS容量 2倍 (1024→2048) | 68-69M | 変化なし |
| Registry lookup削除 | 68-70M | 変化なし |
| Ultra SLIM 4-layer | ~69M | 変化なし |
| **Phase 27-A: Ultra-Inline (全size)** | **56-61M** | **-15% 悪化** ❌ |
| **Phase 27-B: Ultra-Inline (9-512B)** | **61-62M** | **-10% 悪化** ❌ |

### Phase 27 失敗の原因
- Workload の ~52% が headerless classes (cls 0: 1-8B, cls 7: 513-1024B)
- Headerless クラスをフィルタする条件分岐自体が overhead
- Classes 1-6 からの利益 < 条件分岐の overhead

### 残り 25% ギャップの原因（構造的オーバーヘッド）
1. **Header byte オーバーヘッド** - 毎 alloc/free で 1 バイト書き込み/読み込み
2. **TLS SLL カウンタ** - 毎回 count++ / count-- (vs tcache: pointer のみ)
3. **多層分岐** - 4-5層 dispatch (vs tcache: 2-3層)

### 結論
**68-70M ops/s が現アーキテクチャの実質的な限界**。System malloc の 93M ops/s に到達するには:
- Header-free design への全面的な見直し
- tcache 模倣（カウンタ削除、分岐削減）

が必要だが、現時点では投資対効果が低い。

---

## 📁 主要な修正ファイル（Arena Allocator 実装）

- `core/box/ss_cache_box.inc:138-229` - SSArena allocator 追加
- `core/box/tls_sll_box.h:509-561` - Release mode で recycle check オプショナル化
- `core/tiny_free_fast_v2.inc.h:113-148` - Release mode で cross-check 削除
- `core/hakmem_tiny_sll_cap_box.inc:8-25` - C5 容量を full capacity に変更
- `core/hakmem_policy.c:24-30` - min_keep tuning
- `core/tiny_alloc_fast_sfc.inc.h:18-26` - SFC defaults tuning

---

## 🗃 過去の問題と解決（参考）

### Arena Allocator 以前の状態
- **Random Mixed (5M ops)**: ~56-60M ops/s, **mmap 418回** (mimalloc の 26倍)
- **根本原因**: SuperSlab = allocation単位 = cache単位 という設計ミスマッチ
- **問題**: ws=256 では Slab が 5-15% 使用率で停滞 → 完全 EMPTY にならない → LRU キャッシュ不発 → 毎回 mmap/munmap

### Arena Allocator による解決
- SuperSlab を OS 単位として扱う Arena allocator 実装
- mmap 418回 → 32回 (-92%)、munmap 378回 → 3回 (-99%)
- 性能 60M → 68-70M ops/s (+15%)

---

## 📊 他アロケータとのアーキテクチャ対応（参考）

| HAKMEM | mimalloc | tcmalloc | jemalloc |
|--------|----------|----------|----------|
| SuperSlab (2MB) | Segment (~2MiB) | PageHeap | Extent |
| Slab (64KB) | Page (~64KiB) | Span | Run/slab |
| per-class freelist | pages_queue | Central freelist | bin/slab lists |
| Arena allocator | segment cache | PageHeap | extent_avail |

---

## 🚀 将来の可能性（長期）

### Slab-level EMPTY Recycling（未実装）
- **Goal**: Slab を cross-class で再利用可能にする
- **設計**: EMPTY slab を lock-free stack で管理、alloc 時に class_idx を動的割り当て
- **期待効果**: メモリ効率向上（ただし性能向上は限定的）

### Abandoned SuperSlab（MT 用、未実装）
- **Goal**: スレッド終了後のメモリを他スレッドから reclaim
- **設計**: mimalloc の abandoned segments 相当
- **実装タイミング**: MT ワークロードで必要になってから

---

## ✅ 完成したマイルストーン

1. **Arena Allocator 実装** - mmap 95% 削減達成 ✅
2. **Phase 27 調査** - アーキテクチャ限界の確認 ✅
3. **性能 68-70M ops/s** - System malloc の 73-76% に到達 ✅

**現在の推奨**: 68-70M ops/s を baseline として受け入れ、他のワークロード（Mid-Large, Larson 等）の最適化に注力する。