Files
hakmem/docs/status/PHASE6_3_FIX_SUMMARY.md

117 lines
2.9 KiB
Markdown
Raw Normal View History

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
# Phase 6-3 Fast Path: Quick Fix Summary
## Root Cause (TL;DR)
Fast Path implementation creates a **double-layered allocation path** that ALWAYS fails due to SuperSlab OOM:
```
Fast Path → tiny_fast_refill() → hak_tiny_alloc_slow() → OOM (NULL)
Fallback → Box Refactor path → ALSO OOM → crash
```
**Result:** -20% regression (4.19M → 3.35M ops/s) + 45 GB memory leak
---
## 3 Fix Options (Ranked)
### ⭐⭐⭐⭐⭐ Fix #1: Disable Fast Path (IMMEDIATE)
**Time:** 1 minute
**Confidence:** 100%
**Target:** 4.19M ops/s (restore baseline)
```bash
make clean
make BOX_REFACTOR_DEFAULT=1 TINY_FAST_PATH_DEFAULT=0 larson_hakmem
./larson_hakmem 10 8 128 1024 1 12345 4
```
**Why this works:** Reverts to proven Box Refactor path (Phase 6-2.2)
---
### ⭐⭐⭐⭐ Fix #2: Integrate Fast Path with Box Refactor (2-4 hours)
**Confidence:** 80%
**Target:** 5.0-6.0M ops/s (20-40% improvement)
**Change 1:** Make `tiny_fast_refill()` use Box Refactor backend
```c
// File: core/tiny_fastcache.c:tiny_fast_refill()
void* tiny_fast_refill(int class_idx) {
// OLD: void* ptr = hak_tiny_alloc_slow(size, class_idx); // OOM!
// NEW: Use proven Box Refactor path
void* ptr = hak_tiny_alloc(size); // ← This works!
// Rest of refill logic stays the same...
}
```
**Change 2:** Remove Fast Path from `hak_alloc_at()` (avoid double-layer)
```c
// File: core/hakmem.c:hak_alloc_at()
// Comment out lines 682-697 (Fast Path check)
// Keep ONLY in malloc() wrapper (lines 1294-1309)
```
**Why this works:**
- Box Refactor path is proven (4.19M ops/s)
- Fast Path gets actual cache refills
- Subsequent allocations hit 3-4 instruction fast path
- No OOM because Box Refactor handles allocation correctly
---
### ⭐⭐ Fix #3: Fix SuperSlab OOM (1-2 weeks)
**Confidence:** 60%
**Effort:** High (deep architectural change)
Only needed if Fix #2 still has OOM issues. See full analysis for details.
---
## Recommended Sequence
1. **Now:** Run Fix #1 (restore baseline)
2. **Today:** Implement Fix #2 (integrate with Box Refactor)
3. **Test:** A/B compare Fix #1 vs Fix #2
4. **Decision:**
- If Fix #2 > 4.5M ops/s → Ship it! ✅
- If Fix #2 still has OOM → Need Fix #3 (long-term)
---
## Expected Outcomes
| Fix | Time | Score | Status |
|-----|------|-------|--------|
| #1 (Disable) | 1 min | 4.19M ops/s | ✅ Safe baseline |
| #2 (Integrate) | 2-4 hrs | 5.0-6.0M ops/s | 🎯 Target |
| #3 (Root cause) | 1-2 weeks | Unknown | ⚠️ High risk |
---
## Why Statistics Don't Show
`HAKMEM_TINY_FAST_STATS=1` produces no output because:
1. **No shutdown hook** - `tiny_fast_print_stats()` never called
2. **Thread-local counters** - Lost when threads exit
3. **Early crash** - OOM kills benchmark before stats printed
**Fix:** Add to `hak_flush_tiny_exit()` in `hakmem.c`:
```c
// Line ~206
extern void tiny_fast_print_stats(void);
tiny_fast_print_stats();
```
---
**Full analysis:** `PHASE6_3_REGRESSION_ULTRATHINK.md`