hakmem/docs/analysis/PERF_ANALYSIS_TINY_FRONT_FLATTEN_PHASE42.md

# Phase42 Front Route Flatten ベースライン計測

- ビルド: `make bench_random_mixed_hakmem -j4`

## C7-only (ws=64, iters=20000, v2 OFF)
- ENV: `HAKMEM_BENCH_C7_ONLY=1 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_STATS_BOX=1 HAKMEM_TINY_STATS_BATCH=0 HAKMEM_TINY_LARSON_FIX=1`
- 結果: `Throughput = 41365988 ops/s`
- 備考: HEAP_STATS のダンプは出ず（要調査）。FRONT_CLASS: cls7 alloc=11016。

## Mixed 16–1024B (ws=256, iters=20000, v2 OFF)
- ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- 結果: `Throughput = 43538552 ops/s`
- 備考: FRONT_CLASS alloc counts（cls2:147, cls3:341, cls4:720, cls5:1420, cls6:2745, cls7:5692）。HEAP_STATS ダンプは出ず。

## Tiny-only 8–128B (ws=256, iters=20000, v2 OFF) ※任意測定
- ENV: `HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- 結果: `Throughput = 65979164 ops/s`
- 備考: FRONT_CLASS alloc counts（cls2:147, cls3:341, cls4:720, cls5:9857）。HEAP_STATS ダンプは出ず。

# Phase65 後半: 長尺 v2 ON/OFF A/B（ws=400, iters=1M, PROFILE=C7_SAFE）
- 共通 ENV: `HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_HOTHEAP_V2_STATS=1`
## C7-only
- v2 OFF (`HOTHEAP_V2=0`): **38.24M ops/s**, HEAP_STATS[7] fast=550099 slow=1。
- v2 ON (`HOTHEAP_V2=1`, classes=0x80): **38.68M ops/s**, HEAP_STATS[7] fast=550099 slow=1。v2 stats: refill=1、fail/fallback=0。
## Mixed 16–1024B
- v2 OFF: **41.78M ops/s**, HEAP_STATS[7] fast=283169 slow=1。
- v2 ON: **41.94M ops/s**, HEAP_STATS[7] fast=283169 slow=1。v2 stats: refill=1、fail/fallback=0。
- 所感: 長尺では v2 ON/OFF とも slow≈1 に収束し、性能も ±5% 以内（むしろ微プラス）。短尺で見える refill≈50 はウォームアップ由来と判断。

### Phase65/66 サマリ表（1M / ws=400, PROFILE=C7_SAFE）

| プロファイル          | v2 OFF ops/s | v2 ON ops/s | HEAP_STATS[7] slow | 備考                    |
|-----------------------|-------------:|------------:|--------------------:|-------------------------|
| C7-only (C7-only ベンチ) |     38.24M   |     38.68M  |                   1 | v2 は微プラス・refill=1 |
| Mixed 16–1024B        |     41.78M   |     41.94M  |                   1 | v2 は微プラス・refill=1 |

---

# Phase43 (HEAP_STATS 再有効化の再計測) ※v2 OFF

- HEAP_STATS 用 ENV を明示 (`HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1`) したが、現状はダンプが出ていない。fast/slow の値は別途要確認。

## C7-only (ws=64, iters=20000)
- ENV: `HAKMEM_BENCH_C7_ONLY=1 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_STATS_BOX=1 HAKMEM_TINY_STATS_BATCH=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- Throughput: `37,777,547 ops/s`
- HEAP_STATS cls7: fast=11015 slow=1 / free_fast_local=8726、C7_PAGE_STATS: prepare_calls=1 prepare_with_current_null=1
- FRONT_CLASS: cls7 alloc=11016 free=8726

## Mixed 16–1024B (ws=256, iters=20000)
- ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- Throughput: `42,029,698 ops/s`
- HEAP_STATS cls7: fast=5691 slow=1 / free_fast_local=4573（cls5/6 未出力）
- FRONT_CLASS alloc: cls2=147 cls3=341 cls4=720 cls5=1420 cls6=2745 cls7=5692

## Tiny-only 8–128B (ws=256, iters=20000)
- ENV: `HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- Throughput: `65,890,043 ops/s`
- HEAP_STATS: 出力なし（cls7 も 0）→ クラス0〜6は計測対象外の可能性。要調査。

### メモ
- C7-only では HEAP_STATS/PAGE_STATS が出ることを確認。Mixed/Tiny-only では cls7 以外の HEAP_STATS が落ちておらず、環境/計測対象の条件を再確認する余地あり。

# Phase63: C6 v2 A/B（C6-heavy / Mixed, C7 SAFE）
- 共通 ENV: `HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2_STATS=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1`
## C6-heavy (min=257/max=768, ws=400, iters=1M)
- v2 OFF (`HOTHEAP_V2=0`): **42.15M ops/s**, HEAP_STATS[7] fast=283169 slow=1。
- v2 ON (`HOTHEAP_V2=1`, classes=0x40): **29.69M ops/s**。HEAP_STATS[6] fast=266914 slow=16。HOTHEAP_V2_STATS cls6 route_hits=0 / free_fb_v1=266930（実質 v1 経路）、fail=0。
## Mixed 16–1024B (ws=400, iters=1M)
- C7 v2 only (`classes=0x80`): **45.07M ops/s**。HEAP_STATS[7] fast=283170 slow=2276、v2 alloc_lease/refill=2276。
- C6+C7 v2 (`classes=0xC0`): **35.65M ops/s**。HEAP_STATS[6] fast=137306 slow=1 / cls7 slow=2276。HOTHEAP_V2_STATS cls6 route_hits=0、cls7 refills=2276。
- 所感: C6 v2 は初回 A/B で大幅マイナスかつ v2 ルートが当たっていない。C7 v2 もこのプロファイルでは refill が 2,276 件と多く throughput 低下。v2 は研究箱のまま、デフォルトは v2 OFF。

# Phase43'': 計測専用で C6/C7 を TinyHeap に載せた場合（v2 OFF）

## Mixed 16–1024B (ws=256, iters=20000, class mask=0xC0, C6+C7)
- ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HEAP_CLASSES=0xC0 HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_C6_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- Throughput: `32,227,500 ops/s`（性能は大幅に低下、計測専用）
- HEAP_STATS:
  - cls6: fast=2744 slow=1 free_fast_local=2745
  - cls7: fast=5691 slow=1 free_fast_local=4572
- FRONT_CLASS alloc: cls2=147 cls3=341 cls4=720 cls5=1420 cls6=2745 cls7=5692

## Tiny-only 8–128B (ws=256, iters=20000, class mask=0xC0, C6+C7)
- ENV: `HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HEAP_CLASSES=0xC0 HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_C6_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1`
- Throughput: `63,341,251 ops/s`
- HEAP_STATS: 出力なし（対象クラスが 5 未満中心のため？）

### 所感
- C6 を TinyHeap 経由にすると Mixed で大きくマイナス（32M）。cls6/7 の slow はいずれも 1 なので、性能低下はフロント/ホットパスの命令数増が主因と見られる。
- 計測目的でのみクラスマスクを広げるのは有効だが、本番プロファイルは C7 のみ TinyHeap (0x80) を維持するのが安全。

# Phase48: first-touch/page-fault 実験用プロファイルの固定
- 評価は以下で統一し、pf/sys A/B の基準にする:
  - `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1`
  - perf stat メトリクス: ops/s, page-faults, task-clock(user/sys), cycles, instructions
- 目的: HugePage/first-touch 削減などの実験をこのプロファイルで比較し、pf がどれだけ減るかを確認する。

# Phase45: 16–1024B perf stat A/B（HAKMEM vs mimalloc vs system, ws=400, iters=1,000,000, v2 OFF, C7 SAFE）

共通ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024`

| Allocator | Throughput (ops/s) | cycles | instructions | IPC | task-clock | user/sys | page-faults |
|-----------|-------------------:|-------:|-------------:|----:|-----------:|---------:|------------:|
| HAKMEM (C7_SAFE, v2 OFF) | 40,623,450 | 181,136,824 | 372,126,696 | 2.05 | 46.82 ms | 29.4 ms / 18.5 ms | 6,659 |
| mimalloc | 112,895,946 | 38,800,615 | 59,184,115 | 1.53 | 10.66 ms | 10.31 ms / 1.41 ms | 146 |
| system malloc | 92,111,481 | 52,144,974 | 107,607,240 | 2.06 | 12.54 ms | 12.27 ms / 1.36 ms | 133 |

所感/次手候補:
- HAKMEM は sys 時間と page-fault が顕著（pf が mimallocの ~45x, sys 時間が高い）。pf/sys 寄りのボトルネックが支配的に見える。
- 次の箱候補:
  - pf/sys 改善を狙う: Superslab/Warm Pool/pagefault 周りのCold Box見直し。
  - 命令数削減: front整理は済みなので、Tiny v1ホットパスや mid/large を軽くする路線も候補。

### メモ
- HEAP_STATS（fast/slow）のダンプが出ない状態。今後のベンチでは `HAKMEM_TINY_HEAP_STATS[_DUMP]` の有効化経路を再確認する必要あり。

# Phase46: pf/sys 内訳の初期確認（HAKMEM, 16–1024B, ws=400, iters=1,000,000, v2 OFF, C7_SAFE）

- `perf record -o perf.data.pf -e page-faults -- ./bench_random_mixed_hakmem 1000000 400 1`
- `perf report --stdio -i perf.data.pf`
- サマリ: page-fault サンプルの ~96% が `__memset_avx2_unaligned_erms`（初回タッチ系）。カーネル側の munmap/madvise 由来はほぼ見えず、残っている 6.6k faults は first-write が中心と推定。
- 基準プロファイル（以降 pf/sys A/B の基準にする想定）:
  - `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1`
- TODO / 次の箱候補:
  - WarmPool / Superslab 再利用が十分効いているかの stats 確認（該当 ENV を後続で調査）。
  - empty Superslab を即 OS 返却していないかのポリシー確認。
  - pf/sys 系の変更は上記プロファイルで揃えて A/B を取る。

# Phase46': WarmPool stats 1 回だけ確認（Mixed 16–1024B, ws=256, iters=20k, v2 OFF, C7_SAFE）
- ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_WARM_POOL_STATS=1`
- 結果（stderr 抜粋）:
  - WarmPool-STATS: C7 hits=173 / misses=1 / prefilled=1（約 99.4% ヒット）。C2/C3/C4/C6 は warmup/prefill の 1 miss/1 prefill のみ。C0/C1/C5 は 0。
  - WARM logs: `REL_C7_WARM_PREFILL calls=1 slabs=1`, `REL_C7_CARVE attempts=173 success=173`, `REL_C7_WARM pop=174 push=173`.
  - Throughput: 43,809,979 ops/s（ws=256, iters=20k）。
- 所感:
  - C7 は warm pool でほぼヒットしており、残り pf は first-write 優位という推定と矛盾しない。
  - 他クラスの warm pool はほぼ未使用（prefill 1 回のみ）。Mixed での pf/sys は C7 以外の Superslab 利用状況も別途見る必要あり。

# Phase49: Mixed 16–1024B userland-only CPU パス観測（v2 OFF, C7_SAFE）
- ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1`
- perf stat（1M iters, ws=400, userlandのみ）: throughput=41,000,086 ops/s, cycles=126,239,279, instructions=324,810,642（IPC≈2.57）, branch-misses=1,186,675, time=0.0438s（user 0.0295s / sys 0.0143s）
- perf record（cycles:u, 1M/400）上位シンボル（self%基準、子なし集計）:
  - free 24.3%（libc wrapper経由の前段処理）
  - malloc 18.0%
  - main 15.3%（ベンチハーネス）
  - tiny_heap_page_pop 8.8%（TinyHeapBox hot pop）
  - hak_super_lookup 7.9%（frontからの Superslab 判定）
  - tiny_heap_page_becomes_empty 5.9%（empty 処理）
  - __memset_avx2_unaligned_erms 4.0%（ユーザランド側の初期化）
  - tiny_region_id_write_header 2.4%
- 所感: ベンチ前段の malloc/free/main が重いが、TinyHeapBox 側では pop / super_lookup / empty が目立つ。Phase50 では TinyHeapBox（pop/empty + super_lookup 周辺）の枝削減を優先候補にする。

# Phase47: Superslab OS ポリシーと OS 呼び出し可視化
- Superslab取得パス: LRU pop → 旧 cache pop → ss_os_acquire(mmap、必要なら MAP_POPULATE / prefault touch) の順。mmap 成功時に g_ss_mmap_count + SS_OS_STATS alloc を更新。
- Superslab解放パス: registry unregister → LRU push（成功時は MADV_DONTNEED で lazy zero、今回 madvise カウント追加）→ 旧 cache push → どちらも満杯なら即 munmap（SS_OS_STATS free を加算）。ss_cache が容量縮小で munmap した場合も free をカウント。
- 新 ENV: `HAKMEM_SS_OS_STATS=1` で alloc/free/madvise を destructor 1 行でダンプ（`[SS_OS_STATS] alloc=… free=… madvise=…`）。基準プロファイル（16–1024B, ws=400, iters=1M, C7_SAFE, v2 OFF）で 1 回回して OS 呼び出し回数を確認予定。
- SS_OS_STATS（16–1024B, ws=400, iters=1M, C7_SAFE, v2 OFF）: alloc=2 / free=3 / madvise=2 / mmap_total=2 → OS 呼び出しは少数。残る 6.6k pf は first-write 優位と見るのが妥当。

# Phase47: C6-heavy CPU ホットパスの初期観測（v2 OFF, C7_SAFE）

- ベンチ (ws=256, iters=20k, C6-heavy):
  - ENV: `HAKMEM_BENCH_MIN_SIZE=257 HAKMEM_BENCH_MAX_SIZE=768 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1`
  - Throughput: `39,457,304 ops/s`
  - FRONT_CLASS: cls6 alloc/free=5373、cls7 alloc=5692 free=4573
  - HEAP_STATS cls7: fast=5691 slow=1、C7_PAGE_STATS prepare_calls=1
- perf stat (1M, ws=400, same ENV):
  - Throughput: `41,295,709 ops/s`
  - cycles=175,790,796 / instructions=368,496,560 (IPC≈2.10) / task-clock=42.36 ms (user 27.26 ms / sys 16.13 ms) / branch-misses=2,206,657
- perf record (cycles, 1M, ws=400):
  - ホットスポットは匿名ページフォルト経路に集中（`__memset_avx2_unaligned_erms` → `handle_mm_fault` → `do_anonymous_page` が包含 60%超）。
  - ユーザランド側では `free`/`malloc` が目立つがカーネルの first-touch が支配的。
- 所感: C6-heavy でも pf/sys が依然大きく、C6/Tiny フロントより先に first-touch/zero の扱いを考える必要がある（prefault/warm 再利用の検討）。

# Phase50: Tiny ヘッダモード (full/light/off) A/B（first-touch 実験の一部）
- 目的: `tiny_region_id_write_header` のヘッダ書き込み/guard 初期化を軽量化することで page-fault / cycles がどこまで動くかを確認。
- 実装概要:
  - ENV `HAKMEM_TINY_HEADER_MODE=full|light|off` を追加（未指定は full）。
    - `full`: 従来どおり region_id ヘッダと guard/初期化を常に書き戻す。
    - `light`: 既存ヘッダと一致する場合は再書き込みを避け、差分のみ最小限書く。
    - `off`: 既存ヘッダが壊れている場合のみ最小限のヘッダを書き戻し、guard 呼び出しや追加初期化はスキップ（free 整合性の最低限のみ保証）。旧 `HAKMEM_TINY_WRITE_HEADER=0` は off 相当として互換維持。
  - `FIRST_TOUCH_PAGEFAULT_REDUCTION_PLAN.md` に 3 モードの設計と ENV を明記（bench 専用 opt-in モードとして扱う）。

## Mixed 16–1024B (ws=400, iters=1M, PROFILE=C7_SAFE, v2 OFF, LARSON_FIX=1)
- 共通 ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1`
- HEADER_MODE=full:
  - Throughput: **42,399,649 ops/s**
  - cycles: 176,079,783
  - page-faults: 6,662
  - task-clock: 42.16 ms（user 25.1 ms / sys 17.8 ms）
- HEADER_MODE=light:
  - Throughput: **38,752,779 ops/s**
  - cycles: 187,089,553
  - page-faults: 6,661
  - task-clock: 44.16 ms（user 31.5 ms / sys 13.2 ms）
- HEADER_MODE=off:
  - Throughput: **39,330,655 ops/s**
  - cycles: 183,795,801
  - page-faults: 6,662
  - task-clock: 43.43 ms（user 29.3 ms / sys 15.2 ms）

### 所感（ヘッダモード実験）
- page-fault 回数は full/light/off いずれも ≈6.66k とほぼ同一で、ヘッダ書き込み軽量化では first-touch page-fault は減らない。
- cycles/ops はむしろ full が最も良く、light/off はそれぞれ約 -9% / -7% 程度の性能低下。判定・分岐コストがヘッダ書き込み削減効果を上回っている。
- 結論として、現時点の実装では **運用デフォルトは full のままが最良**。light/off は bench 専用の実験モードとして残し、本番プロファイルでは使用しない前提とする。

# Phase52: Superslab HugePage 実験 (Mode A) – 初期結果
- 目的: Superslab を HugePage (2MB) で確保する実験経路を追加し、page-fault / sys 時間がどこまで動くかを見る（研究専用）。
- 実装概要:
  - ENV:
    - `HAKMEM_SS_HUGEPAGE_EXPERIMENT=1` で HugePage 経路を opt-in（デフォルト 0）。
    - `HAKMEM_SS_HUGEPAGE_SIZE` でページサイズを指定（現状は "2M" 前提で実装）。
  - `ss_os_acquire` 周辺に HugePage 試行を追加し、`MAP_HUGETLB | MAP_HUGE_2MB` で `mmap` を試し、失敗時は即通常の 1MB Superslab 経路にフォールバック。
  - SS_OS_STATS に `huge_alloc` / `huge_fail` を追加し、`HAKMEM_SS_OS_STATS=1` で `[SS_OS_STATS] alloc=.. free=.. madvise=.. huge_alloc=.. huge_fail=..` を 1 行出力。

## Mixed 16–1024B (ws=400, iters=1M, PROFILE=C7_SAFE, v2 OFF, LARSON_FIX=1)
- 共通 ENV: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_SS_OS_STATS=1`
- HugePage OFF:
  - Throughput: **41,464,379 ops/s**
  - cycles: 180,862,510
  - page-faults: 6,660
  - SS_OS_STATS: `alloc=2 free=4 madvise=2 mmap_total=2 fallback_mmap=0 huge_alloc=0 huge_fail=0`
- HugePage ON (`HAKMEM_SS_HUGEPAGE_EXPERIMENT=1`, `HAKMEM_SS_HUGEPAGE_SIZE=2M`):
  - Throughput: **41,372,856 ops/s**
  - cycles: 177,305,948
  - page-faults: 6,662
  - SS_OS_STATS: `alloc=2 free=4 madvise=2 mmap_total=2 fallback_mmap=0 huge_alloc=0 huge_fail=0`

### 所感（HugePage 実験初期結果）
- 現状の Superslab サイズ/条件では HugePage 経路が一度もヒットせず（`huge_alloc=0` / `huge_fail=0`）、通常 Superslab 経路のみが使用されている。
- そのため HugePage ON/OFF で throughput / cycles / page-fault はほぼ同一となり、初期実装の段階では効果は「ゼロに近い」。
- 2MB Superslab 専用クラスを設計するか、サイズ条件を緩めて HugePage を実際に使うかを決めないと、Mode A の効果は評価できない。
- 一方で pf はすでに ≈6.6k と小さく、たとえ HugePage でさらに削っても全体への寄与は限定的なため、現時点では **CPU ホットパス側の最適化を優先し、HugePage 実験は research-only の位置付けに留める** のが妥当と見える。

## Phase59: C7 HotHeap v2 Mixed A/B（C7-only route ON/OFF）
- プロファイル: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_HOTHEAP_CLASSES=0x80`
- v2 OFF (`HAKMEM_TINY_HOTHEAP_V2=0`):
  - Throughput: **45,113,732 ops/s**
  - HEAP_STATS[7]: fast=5691 slow=1
  - C7_PAGE_STATS: prepare_calls=1（current を握り続けている）
- v2 ON (`HAKMEM_TINY_HOTHEAP_V2=1`, `HAKMEM_TINY_HOTHEAP_V2_STATS=1`):
  - Throughput: **46,209,226 ops/s**（約 +2.4%）
  - HEAP_STATS[7]: fast=5692 slow=45
  - HOTHEAP_V2_C7_STATS: route_hits=5692, alloc_fast=5692, alloc_lease=45 (=refill=45), cold_refill_fail=0, free_fast=4376, page_retired=4, fallback_v1=0
- 所感:
  - Mixed でも v2 ON で微増（+2〜3%）だが、slow_prepare/alloc_lease が 45 と多く、current/partial を使い切る前に refill が走っている可能性がある。
  - cold_refill_fail/fallback は 0 のため、境界は安定。次は v2 内で空ページを握る／refill の発生頻度を下げる調整が必要。

## Phase60: C7 HotHeap v2 空ページ保持ポリシー（partial 温存）初期ベンチ
- 変更点: `max_partial_pages` を C7 用に 2 へ設定し、free で `used==0` のページは retire せず partial へ温存。partial が上限を超えたときだけ retire。partial push/pop/peak/retire_v2 を v2 stats に追加。
- C7-only (ws=64, iters=20k, PROFILE=C7_SAFE):
  - v2 OFF: **41.94M ops/s**, HEAP_STATS[7] fast=11015 slow=1。
  - v2 ON: **50.43M ops/s**, HEAP_STATS[7] fast=11016 slow=48。HOTHEAP_V2_C7_STATS: alloc_lease=48 (=refill), partial_push/pop/peak=0, retire_v2=0。
  - メモ: workload が常時多数の live ブロックを持つため page が空にならず、partial_push/retire はまだ発火していない。slow≈refill となっており、ページ容量/同時 live 数が原因と推定。
- Mixed 16–1024B (ws=256, iters=20k, PROFILE=C7_SAFE):
  - v2 OFF: **42.82M ops/s**, HEAP_STATS[7] fast=5691 slow=1。
  - v2 ON: **47.71M ops/s**, HEAP_STATS[7] fast=5692 slow=42。HOTHEAP_V2_C7_STATS: alloc_lease=42 (=refill), partial_push/pop/peak=0, retire_v2=0。
- 所感:
  - slow_prepare は「refill したページ数」と一致しており、空ページ保持ポリシーはまだ効く場面に遭遇していない（ページが一度も空にならないワークロード）。
  - v2 は C7-only/Mixed ともプラスを維持（+20% 近い向上）だが、refill=slow が 40〜50 回発生。partial を効かせるには「空になるページ」が出るプロファイルで検証するか、ページ容量/lease 戦略の見直しが必要。
- 備考（容量と live 数）:
  - C7 の page capacity は 32 blocks（約 32KiB）で、ws=64/256/400 の Mixed では常時多数の live ブロックが存在するため、空 page がほぼ発生しない。partial/retire は保険として温存しつつ、現行ベンチでは出番がない前提で扱う。

## Phase61: C7 v2 長尺 Mixed (ws=400, iters=1M) 安定性確認
- プロファイル: Mixed 16–1024B, ws=400, iters=1M, PROFILE=C7_SAFE, C7_HOT=1, v2 classes=0x80, LARSON_FIX=1, STATS_BOX=on, STATS_BATCH=0。
- v2 OFF: **41.58M ops/s**。HEAP_STATS[7] fast=283169 slow=1。cold_refill_fail=0, fallback_v1=0。
- v2 ON: **42.41M ops/s**（約 +2%）。HEAP_STATS[7] fast=283169 slow=1。v2 stats dumpはなし（fail/fallbackなし）。
- 所感:
  - 長尺でも v2 ON で安定稼働し、+2% 程度の改善を維持。slow_prepare は 1 に張り付き、短尺で見えていた refill 多発は長尺では再現せず。
  - 引き続き v2 は C7-only の研究箱（デフォルト OFF）のまま、Mixed でも回帰しないことを確認。

### Phase61’(短尺再確認): Mixed 16–1024B (ws=256, iters=20k)
- v2 OFF: **43.27M ops/s**, HEAP_STATS[7] fast=5691 slow=1。
- v2 ON (C7-only v2, classes=0x80, v2 stats ON): **44.57M ops/s**（約 +3%）、HEAP_STATS[7] fast=5691 slow=1、cold_refill_fail/fallback=0。C7_PAGE_STATS: prepare_calls=1 で安定。
- 所感: 20k/256 でも slow_prepare は 1 に収まり、v2 ON で軽いプラスを維持。長尺と同様に安定。partial/retire ポリシーは依然発火せず（ページが空にならない負荷のため）、本線 Mixed では v2 を研究箱として継続しつつ、さらなる薄型化/slow圧縮を検討。