ChatGPT's diagnostic changes to address TLS_SLL_HDR_RESET issue. Current status: Partial mitigation, but root cause remains. Changes Applied: 1. SuperSlab Registry Fallback (hakmem_super_registry.h) - Added legacy table probe when hash map lookup misses - Prevents NULL returns for valid SuperSlabs during initialization - Status: ✅ Works but may hide underlying registration issues 2. TLS SLL Push Validation (tls_sll_box.h) - Reject push if SuperSlab lookup returns NULL - Reject push if class_idx mismatch detected - Added [TLS_SLL_PUSH_NO_SS] diagnostic message - Status: ✅ Prevents list corruption (defensive) 3. SuperSlab Allocation Class Fix (superslab_allocate.c) - Pass actual class_idx to sp_internal_allocate_superslab - Prevents dummy class=8 causing OOB access - Status: ✅ Root cause fix for allocation path 4. Debug Output Additions - First 256 push/pop operations traced - First 4 mismatches logged with details - SuperSlab registration state logged - Status: ✅ Diagnostic tool (not a fix) 5. TLS Hint Box Removed - Deleted ss_tls_hint_box.{c,h} (Phase 1 optimization) - Simplified to focus on stability first - Status: ⏳ Can be re-added after root cause fixed Current Problem (REMAINS UNSOLVED): - [TLS_SLL_HDR_RESET] still occurs after ~60 seconds of sh8bench - Pointer is 16 bytes offset from expected (class 1 → class 2 boundary) - hak_super_lookup returns NULL for that pointer - Suggests: Use-After-Free, Double-Free, or pointer arithmetic error Root Cause Analysis: - Pattern: Pointer offset by +16 (one class 1 stride) - Timing: Cumulative problem (appears after 60s, not immediately) - Location: Header corruption detected during TLS SLL pop Remaining Issues: ⚠️ Registry fallback is defensive (may hide registration bugs) ⚠️ Push validation prevents symptoms but not root cause ⚠️ 16-byte pointer offset source unidentified Next Steps for Investigation: 1. Full pointer arithmetic audit (Magazine ⇔ TLS SLL paths) 2. Enhanced logging at HDR_RESET point: - Expected vs actual pointer value - Pointer provenance (where it came from) - Allocation trace for that block 3. Verify Headerless flag is OFF throughout build 4. Check for double-offset application in conversions Technical Assessment: - 60% root cause fixes (allocation class, validation) - 40% defensive mitigation (registry fallback, push rejection) Performance Impact: - Registry fallback: +10-30 cycles on cold path (negligible) - Push validation: +5-10 cycles per push (acceptable) - Overall: < 2% performance impact estimated Related Issues: - Phase 1 TLS Hint Box removed temporarily - Phase 2 Headerless blocked until stability achieved 🤖 Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
6.9 KiB
6.9 KiB
Learning Layer Overview (ACE / ELO / CAP Learner)
このドキュメントは、hakmem 内の「学習する箱」を縦に貫いて整理した総覧です。 実装は複数のファイル・フェーズに分かれていますが、Box Theory の観点では次の 3 つの箱に分解できます。
1. Box A: ELO + Evolution (L2 / BigCache / THP)
範囲
- サイズ帯: おおむね
≥ 2MB(BigCache / THP / batch madvise が関わる領域) - 箱の責務:
- 大きな割り当てに対する
mmap閾値(いつ BigCache / THP を使うか)の選択 - 戦略候補(しきい値)間の比較と「勝ち残り」管理
- 大きな割り当てに対する
実装ファイル
core/hakmem_elo.{c,h}— ELO Rating Strategy Selection(複数のしきい値候補にレーティング)core/hakmem_evo.h— LEARN → FROZEN → CANARY ライフサイクルcore/hakmem_config.{c,h}—HAKMEM_MODEと Features(HAKMEM_FEATURE_ELO,HAKMEM_FEATURE_EVOLUTION)core/box/mid_large_config_box.h—MID_LARGE_ELO_ENABLEDマクロ(PGO/通常モード)
モード
- FROZEN(デフォルト)
HAKMEM_MODE=balanced/fastではfeatures.learningに ELO は含まれるが、evo_phase = EVO_PHASE_FROZEN。- 戦略は事前に決めたしきい値を使い続け、ランタイムでのレーティング更新は行わない。
- LEARN(開発・研究用)
HAKMEM_MODE=learning/researchでHAKMEM_FEATURE_EVOLUTIONが有効。- ELO レーティングと Evolution 状態機械が動作し、しきい値を動的に調整。
Box Theory 観点
- Hot path(実際の割り当て)は「現在のしきい値」を見るだけ。
- レーティング更新・進化は 完全にオフパス(バックグラウンド) の箱に閉じ込める。
- 切り戻しは:
HAKMEM_MODE変更、またはHAKMEM_DISABLE_ELO=1で ELO を丸ごと無効化。
2. Box B: ACE Controller (L1 Mid/Large, UCB1-based Knob Tuning)
範囲
- サイズ帯: 1KB〜2MB(L1 ACE レイヤ: Mid / Large Pool)
- 箱の責務:
- Mid/Large Pool の TLS capacity / drain threshold / bundle width などの「ノブ」を UCB1 で自動調整。
- 断片化ストレスや巨大ワーキングセットに対して、オフパスでキャッシュ構成を最適化。
実装ファイル
core/hakmem_ace_controller.{c,h}— ACE Controller 本体core/hakmem_ace_metrics.{c,h}— メトリクス収集箱(throughput, llc_miss, backlog 等)core/hakmem_ace_ucb1.{c,h}— UCB1 Multi-Armed Bandit 実装core/box/hak_core_init.inc.h—hkm_ace_controller_init()/hkm_ace_controller_start()呼び出し
起動条件(ENV)
HAKMEM_ACE_ENABLED=1で有効化(デフォルト 0)- 主な補助 ENV:
HAKMEM_ACE_FAST_INTERVAL_MS(デフォルト 500ms)HAKMEM_ACE_SLOW_INTERVAL_MS(デフォルト 30000ms)HAKMEM_ACE_LOG_LEVEL(0=off,1=info,2=debug)
挙動
- 有効時:
- バックグラウンドで fast-loop / slow-loop を回し、
compute_reward()の結果を UCB1 に渡してノブを更新。 - Tiny / Mid / Large のホットパスは「現在のノブ値」を読むだけで、学習ロジックには触れない。
- バックグラウンドで fast-loop / slow-loop を回し、
- 無効時:
hkm_ace_controller_init()が早期 return し、ACE に関連するオーバーヘッドはほぼゼロ。
Box Theory 観点
- ACE は「ポリシー箱」であり、実際の割り当て/解放箱には侵入しない。
- 境界:
- ノブの読み出しは
mid_large_config_box等の 1 箇所 から行う。 - メトリクスの書き込みは
hakmem_ace_metricsに集約(alloc/free 側は軽量カウンタ更新のみ)。
- ノブの読み出しは
3. Box C: CAP/W_MAX Learner + Tiny ACE Observer
範囲
- Mid/Large Pool:
- クラス別 CAP(ページ数 / バンドル数)と W_MAX(許容丸め率)の自動調整。
- Tiny:
hak_tiny_superslab_ace_observe_all()による Tiny Superslab 利用状況の観測(Phase 8.4)。
実装ファイル
core/hakmem_learner.{c,h}— CAP/W_MAX/THP 学習スレッドcore/hakmem_tiny_superslab.h— Tiny Superslab 監視用 API(ACE Observer)core/box/hak_core_init.inc.h—hkm_learner_init()呼び出し
起動条件(ENV)
- 学習スレッド:
HAKMEM_LEARN=1で有効化(デフォルト 0)。
- Tiny ACE Observer:
HAKMEM_ACE_OBSERVE=1で Tiny Superslab の観測を ON。- 追加で
HAKMEM_ACE_DEBUG=1を付けると、観測呼び出しをログ出力。
挙動
- 学習スレッドは:
- 一定間隔(
HAKMEM_LEARN_WINDOW_MS)でヒット率をサンプリング。 - 目標ヒット率 (
HAKMEM_TARGET_HIT_MID/LARGE) とのズレに応じて CAP を増減。 - オプションで W_MAX 候補を UCB1 で試す(
HAKMEM_WMAX_LEARN=1)。
- 一定間隔(
- Tiny ACE Observer は:
- Superslab / Tiny キャッシュの利用状況をスキャンし、後続の設計/学習に使う「観測専用箱」。
- 現時点では Tiny の動作そのものは変えず、将来の ACE-Alloc 設計のための下準備。
Box Theory 観点
- CAP/W_MAX の調整は、
hakmem_learner箱の中だけで完結。 - Mid/Large のホットパスは「現在の CAP / W_MAX」を見るだけで、学習状態を知らない。
- Tiny は「Observer に観測される側」であり、ACE が Tiny のホットパスを直接いじらない設計になっている。
4. モードと組み合わせ(どこまで学習させるか)
グローバルモード (HAKMEM_MODE)
minimal:- ELO/ACE/CAP Learner などの学習箱はすべて OFF。
fast/balanced(デフォルト):- ELO: FROZEN(学習オフ、しきい値のみ利用)
- ACE Controller:
HAKMEM_ACE_ENABLEDが 1 のときのみ動作 - CAP Learner:
HAKMEM_LEARNが 1 のときのみ動作
learning/research:- ELO: LEARN + EVOLUTION 有効
- その他の箱も ENV に応じて積極的に動く前提。
推奨パターン(論文用 / 評価用)
- Baseline:
HAKMEM_MODE=balanced、HAKMEM_ACE_ENABLED=0、HAKMEM_LEARN=0
- ACE only:
HAKMEM_MODE=balanced、HAKMEM_ACE_ENABLED=1、HAKMEM_LEARN=0
- CAP/W_MAX only:
HAKMEM_MODE=balanced、HAKMEM_ACE_ENABLED=0、HAKMEM_LEARN=1
- Full learning:
HAKMEM_MODE=learning、HAKMEM_ACE_ENABLED=1、HAKMEM_LEARN=1
各パターンのベンチ結果は、docs/benchmarks/LEARNING_AB_RESULTS.md に逐次追記していく想定です。
5. 関連ドキュメント
- 概要・設計:
docs/ACE_LEARNING_LAYER.mddocs/ACE_LEARNING_LAYER_PLAN.mddocs/design/ARCHITECTURE_DESIGN.md
- 詳細分析:
docs/analysis/ACE_INVESTIGATION_REPORT.mddocs/analysis/ACE_POOL_ARCHITECTURE_INVESTIGATION.mddocs/analysis/ENV_CLEANUP_ANALYSIS.md
- 論文ドラフト:
docs/paper/ACE-Alloc/main.md- メモ用:
docs/paper/ACE_ALLOC_NOTES.md(今後作成・拡充予定)