707056b765
Performance Achievements: - Tiny allocations: +180-280% (21M → 59-70M ops/s random mixed) - Single-thread: +24% (2.71M → 3.36M ops/s Larson) - 4T stability: 0% → 95% (19/20 success rate) - Overall: 91.3% of System malloc average (target was 40-55%) ✓ Phase 7 (Tasks 1-3): Core Optimizations - Task 1: Header validation removal (Region-ID direct lookup) - Task 2: Aggressive inline (TLS cache access optimization) - Task 3: Pre-warm TLS cache (eliminate cold-start penalty) Result: +180-280% improvement, 85-146% of System malloc Critical Bug Fixes: - Fix 64B allocation crash (size-to-class +1 for header) - Fix 4T wrapper recursion bugs (BUG #7, #8, #10, #11) - Remove malloc fallback (30% → 50% stability) Phase 2a: SuperSlab Dynamic Expansion (CRITICAL) - Implement mimalloc-style chunk linking - Unlimited slab expansion (no more OOM at 32 slabs) - Fix chunk initialization bug (bitmap=0x00000001 after expansion) Files: core/hakmem_tiny_superslab.c/h, core/superslab/superslab_types.h Result: 50% → 95% stability (19/20 4T success) Phase 2b: TLS Cache Adaptive Sizing - Dynamic capacity: 16-2048 slots based on usage - High-water mark tracking + exponential growth/shrink - Expected: +3-10% performance, -30-50% memory Files: core/tiny_adaptive_sizing.c/h (new) Phase 2c: BigCache Dynamic Hash Table - Migrate from fixed 256×8 array to dynamic hash table - Auto-resize: 256 → 512 → 1024 → 65,536 buckets - Improved hash function (FNV-1a) + collision chaining Files: core/hakmem_bigcache.c/h Expected: +10-20% cache hit rate Design Flaws Analysis: - Identified 6 components with fixed-capacity bottlenecks - SuperSlab (CRITICAL), TLS Cache (HIGH), BigCache/L2.5 (MEDIUM) - Report: DESIGN_FLAWS_ANALYSIS.md (11 chapters) Documentation: - 13 comprehensive reports (PHASE*.md, DESIGN_FLAWS*.md) - Implementation guides, test results, production readiness - Bug fix reports, root cause analysis Build System: - Makefile: phase7 targets, PREWARM_TLS flag - Auto dependency generation (-MMD -MP) for .inc files Known Issues: - 4T stability: 19/20 (95%) - investigating 1 failure for 100% - L2.5 Pool dynamic sharding: design only (needs 2-3 days integration) 🤖 Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
8.1 KiB
8.1 KiB
HAKMEM Design Flaws - Quick Reference
Date: 2025-11-08 Key Insight: "キャッシュ層って足らなくなったら動的拡張するものではないですかにゃ？" ← 100% CORRECT
Visual Summary
┌─────────────────────────────────────────────────────────────────┐
│ HAKMEM Resource Management │
│ Fixed vs Dynamic Analysis │
└─────────────────────────────────────────────────────────────────┘
Component │ Type │ Capacity │ Expansion │ Priority
───────────────────┼────────────────┼───────────────┼──────────────┼──────────
SuperSlab │ Fixed Array │ 32 slabs │ ❌ None │ 🔴 CRITICAL
└─ slabs[] │ │ COMPILE-TIME │ │ 4T OOM!
│ │ │ │
TLS Cache │ Fixed Cap │ 256-768 slots │ ❌ None │ 🟡 HIGH
└─ g_tls_sll_* │ │ ENV override │ │ No adapt
│ │ │ │
BigCache │ Fixed 2D Array │ 256×8 = 2048 │ ❌ Eviction │ 🟡 MEDIUM
└─ g_cache[][] │ │ COMPILE-TIME │ │ Hash coll
│ │ │ │
L2.5 Pool │ Fixed Shards │ 64 shards │ ❌ None │ 🟡 MEDIUM
└─ freelist[][] │ │ COMPILE-TIME │ │ Contention
│ │ │ │
Mid Registry │ Dynamic Array │ 64 → 2x │ ✅ Grows │ ✅ GOOD
└─ entries │ │ RUNTIME mmap │ │ Correct!
│ │ │ │
Mid TLS Ring │ Fixed Array │ 48 slots │ ❌ Overflow │ 🟢 LOW
└─ items[] │ │ to LIFO │ │ Minor
Problem: SuperSlab Fixed 32 Slabs (CRITICAL)
Current Design (BROKEN):
┌────────────────────────────────────────────┐
│ SuperSlab (2MB) │
│ ┌────────────────────────────────────────┐ │
│ │ slabs[32] ← FIXED ARRAY! │ │
│ │ [0][1][2]...[31] ← Cannot grow! │ │
│ └────────────────────────────────────────┘ │
│ │
│ 4T high-contention: │
│ Thread 1: slabs[0-7] ← all busy │
│ Thread 2: slabs[8-15] ← all busy │
│ Thread 3: slabs[16-23] ← all busy │
│ Thread 4: slabs[24-31] ← all busy │
│ → OOM! No more slabs! │
└────────────────────────────────────────────┘
Proposed Fix (Mimalloc-style):
┌────────────────────────────────────────────┐
│ SuperSlabChunk (2MB) │
│ ┌────────────────────────────────────────┐ │
│ │ slabs[32] (initial) │ │
│ └────────────────────────────────────────┘ │
│ ↓ link on overflow │
│ ┌────────────────────────────────────────┐ │
│ │ slabs[32] (expansion chunk) │ │
│ └────────────────────────────────────────┘ │
│ ↓ can continue growing │
│ ... │
│ │
│ 4T high-contention: │
│ Chunk 1: slabs[0-31] ← full │
│ → Allocate Chunk 2 │
│ Chunk 2: slabs[32-63] ← expand! │
│ → No OOM! │
└────────────────────────────────────────────┘
Comparison: HAKMEM vs Other Allocators
┌─────────────────────────────────────────────────────────────────┐
│ Dynamic Expansion │
└─────────────────────────────────────────────────────────────────┘
mimalloc:
Segment → Pages → Blocks
✅ Variable segment size
✅ Dynamic page allocation
✅ Adaptive thread cache
jemalloc:
Chunk → Runs → Regions
✅ Variable chunk size
✅ Dynamic run creation
✅ Adaptive tcache
HAKMEM:
SuperSlab → Slabs → Blocks
❌ Fixed 2MB SuperSlab size
❌ Fixed 32 slabs per SuperSlab ← PROBLEM!
❌ Fixed TLS cache capacity
✅ Dynamic Mid Registry (only this!)
Fix Priority Matrix
High Impact
▲
│
┌────────────┼────────────┐
│ SuperSlab │ │
│ (32 slabs) │ TLS Cache │
│ 🔴 CRITICAL│ (256-768) │
│ 7-10 days │ 🟡 HIGH │
│ │ 3-5 days │
├────────────┼────────────┤
│ BigCache │ L2.5 Pool │
│ (256×8) │ (64 shards)│
│ 🟡 MEDIUM │ 🟡 MEDIUM │
│ 1-2 days │ 2-3 days │
└────────────┼────────────┘
│
▼
Low Impact
◄────────────┼────────────►
Low Effort High Effort
Quick Stats
Total Components Analyzed: 6
├─ CRITICAL issues: 1 (SuperSlab)
├─ HIGH issues: 1 (TLS Cache)
├─ MEDIUM issues: 2 (BigCache, L2.5)
├─ LOW issues: 1 (Mid TLS Ring)
└─ GOOD examples: 1 (Mid Registry) ✅
Estimated Fix Effort: 13-20 days
├─ Phase 2a (SuperSlab): 7-10 days
├─ Phase 2b (TLS Cache): 3-5 days
└─ Phase 2c (Others): 3-5 days
Expected Outcomes:
✅ 4T stable operation (no OOM)
✅ Adaptive performance (hot classes get more cache)
✅ Better memory efficiency (no over-provisioning)
Key Takeaways
-
User is 100% correct: Cache layers should expand dynamically.
-
Root cause of 4T crashes: SuperSlab fixed 32-slab array.
-
Mid Registry is the gold standard: Use its pattern for other components.
-
Design principle: "Resources should expand on-demand, not be pre-allocated."
-
Fix order: SuperSlab → TLS Cache → BigCache → L2.5 Pool.
Full Analysis: See DESIGN_FLAWS_ANALYSIS.md (11 chapters, detailed roadmap)