Files
hakmem/CURRENT_TASK.md

160 lines
4.3 KiB
Markdown
Raw Normal View History

refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
# Current Task: ACE Investigation - Mid-Large Performance Recovery
feat: Phase 7 + Phase 2 - Massive performance & stability improvements 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>
2025-11-08 17:08:00 +09:00
**Date**: 2025-11-08
**Status**: 🔄 IN PROGRESS
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Priority**: CRITICAL
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
---
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## 🎉 Recent Achievements
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
### 100% Stability Fix (Commit 616070cf7)
-**50/50 consecutive 4T runs passed**
- ✅ Bitmap semantics corrected (0xFFFFFFFF = full)
- ✅ Race condition fixed with mutex protection
- ✅ User requirement MET: "5%でもクラッシュおこったら使えない" → **0% crash rate**
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
### Comprehensive Benchmark Results (2025-11-08)
Located at: `benchmarks/results/comprehensive_20251108_214317/`
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Performance Summary:**
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
| Category | HAKMEM | vs System | vs mimalloc | Status |
|----------|--------|-----------|-------------|--------|
| **Tiny Hot Path** | 218.65 M/s | **+48.5%** 🏆 | **+23.0%** 🏆 | **HUGE WIN** |
| Random Mixed 128B | 16.92 M/s | 34% | 28% | Good (+3-4x from Phase 6) |
| Random Mixed 256B | 17.59 M/s | 42% | 32% | Good |
| Random Mixed 512B | 15.61 M/s | 42% | 33% | Good |
| Random Mixed 2048B | 11.14 M/s | 50% | 65% | Competitive |
| Random Mixed 4096B | 8.13 M/s | 61% | 66% | Competitive |
| Larson 1T | 3.92 M/s | 28% | - | Needs work |
| Larson 4T | 7.55 M/s | 45% | - | Needs work |
| **Mid-Large MT** | 1.05 M/s | **-88%** 🔴 | **-86%** 🔴 | **CRITICAL ISSUE** |
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Key Findings:**
1.**First time beating BOTH System and mimalloc** (Tiny Hot Path)
2.**100% stability** - All benchmarks passed without crashes
3. 🔴 **Critical regression**: Mid-Large MT performance collapsed (-88%)
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
feat: Phase 7 + Phase 2 - Massive performance & stability improvements 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>
2025-11-08 17:08:00 +09:00
---
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Objective: Investigate ACE for Mid-Large Performance Recovery
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Problem:**
- Mid-Large MT: 1.05M ops/s (was +171% in docs, now -88%)
- Root cause (from Task Agent report):
- ACE disabled → all mid allocations go to mmap (slow)
- This used to be HAKMEM's strength
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Goal:**
- Understand why ACE is disabled
- Determine if re-enabling ACE can recover performance
- If yes, implement ACE enablement
- If no, find alternative optimization
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Note:** HAKX is legacy code, ignore it. Focus on ACE mechanism.
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
---
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Task for Task Agent (Ultrathink Required)
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
### Investigation Scope
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
1. **ACE Current State**
- Why is ACE disabled?
- What does ACE do? (Adaptive Cache Engine)
- How does it help Mid-Large allocations?
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
2. **Code Analysis**
- Find ACE enablement flags
- Find ACE initialization code
- Find ACE allocation path
- Understand ACE vs mmap decision
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
3. **Root Cause**
- Why does disabling ACE cause -88% regression?
- What is the overhead of mmap for every allocation?
- Can we fix this by re-enabling ACE?
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
4. **Proposed Solution**
- If ACE can be safely re-enabled: How?
- If ACE has bugs: What needs fixing?
- Alternative optimizations if ACE is not viable
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
5. **Implementation Plan**
- Step-by-step plan to recover Mid-Large performance
- Estimated effort (days)
- Risk assessment
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
---
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Success Criteria
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Understand ACE mechanism and current state**
**Identify why Mid-Large performance collapsed**
**Propose concrete solution with implementation plan**
**Return detailed analysis report**
feat: Phase 7 + Phase 2 - Massive performance & stability improvements 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>
2025-11-08 17:08:00 +09:00
---
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Context for Task Agent
feat: Phase 7 + Phase 2 - Massive performance & stability improvements 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>
2025-11-08 17:08:00 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Current Build Flags:**
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
```bash
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1
feat: Phase 7 + Phase 2 - Massive performance & stability improvements 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>
2025-11-08 17:08:00 +09:00
```
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Relevant Files to Check:**
- `core/hakmem_ace*.c` - ACE implementation
- `core/hakmem_mid_mt.c` - Mid-Large allocator
- `core/hakmem_learner.c` - Learning mechanism
- Build flags in Makefile
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Benchmark to Verify:**
```bash
# Mid-Large MT (currently broken)
./bench_mid_large_mt_hakmem
# Expected: Should improve significantly with ACE
Perf: Phase 7-1.3 - Hybrid mincore + Macro fix (+194-333%) ## Summary Fixed CRITICAL bottleneck (mincore overhead) and macro definition bug. Result: 2-3x performance improvement across all benchmarks. ## Performance Results - Larson 1T: 631K → 2.73M ops/s (+333%) 🚀 - bench_random_mixed (128B): 768K → 2.26M ops/s (+194%) 🚀 - bench_random_mixed (512B): → 1.43M ops/s (new) - [HEADER_INVALID] messages: Many → ~Zero ✅ ## Changes ### 1. Hybrid mincore Optimization (317-634x faster) **Problem**: `hak_is_memory_readable()` calls mincore() syscall on EVERY free - Cost: 634 cycles/call - Impact: 40x slower than System malloc **Solution**: Check alignment BEFORE calling mincore() - Step 1 (1-byte header): `if ((ptr & 0xFFF) == 0)` → only 0.1% call mincore - Step 2 (16-byte header): `if ((ptr & 0xFFF) < HEADER_SIZE)` → only 0.4% call mincore - Result: 634 → 1-2 cycles effective (99.6% skip mincore) **Files**: - core/tiny_free_fast_v2.inc.h:53-71 - Step 1 hybrid check - core/box/hak_free_api.inc.h:94-107 - Step 2 hybrid check - core/hakmem_internal.h:281-312 - Performance warning added ### 2. HAK_RET_ALLOC Macro Fix (CRITICAL BUG) **Problem**: Macro definition order prevented Phase 7 header write - hakmem_tiny.c:130 defined legacy macro (no header write) - tiny_alloc_fast.inc.h:67 had `#ifndef` guard → skipped! - Result: Headers NEVER written → All frees failed → Slow path **Solution**: Force Phase 7 macro to override legacy - hakmem_tiny.c:119 - Added `#ifndef HAK_RET_ALLOC` guard - tiny_alloc_fast.inc.h:69-72 - Added `#undef` before redefine ### 3. Magic Byte Fix **Problem**: Release builds don't write magic byte, but free ALWAYS checks it - Result: All headers marked as invalid **Solution**: ALWAYS write magic byte (same 1-byte write, no overhead) - tiny_region_id.h:50-54 - Removed `#if !HAKMEM_BUILD_RELEASE` guard ## Technical Details ### Hybrid mincore Effectiveness | Case | Frequency | Cost | Weighted | |------|-----------|------|----------| | Normal (Step 1) | 99.9% | 1-2 cycles | 1-2 | | Page boundary | 0.1% | 634 cycles | 0.6 | | **Total** | - | - | **1.6-2.6 cycles** | **Improvement**: 634 → 1.6 cycles = **317-396x faster!** ### Macro Fix Impact **Before**: HAK_RET_ALLOC(cls, ptr) → return (ptr) // No header write **After**: HAK_RET_ALLOC(cls, ptr) → return tiny_region_id_write_header((ptr), (cls)) **Result**: Headers properly written → Fast path works → +194-333% performance ## Investigation Task Agent Ultrathink analysis identified: 1. mincore() syscall overhead (634 cycles) 2. Macro definition order conflict 3. Release/Debug build mismatch (magic byte) Full report: PHASE7_DESIGN_REVIEW.md (23KB, 758 lines) ## Related - Phase 7-1.0: PoC implementation (+39%~+436%) - Phase 7-1.1: Dual-header dispatch (Task Agent) - Phase 7-1.2: Page boundary SEGV fix (100% crash-free) - Phase 7-1.3: Hybrid mincore + Macro fix (this commit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 04:50:41 +09:00
```
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
---
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Deliverables
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
1. **ACE Analysis Report** (markdown)
- ACE mechanism explanation
- Current state diagnosis
- Root cause of -88% regression
- Proposed solution
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
2. **Implementation Plan**
- Concrete steps to fix
- Code changes needed
- Testing strategy
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
3. **Risk Assessment**
- Stability impact
- Performance trade-offs
- Alternative approaches
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
---
Fix: CRITICAL multi-threaded freelist/remote queue race condition Root Cause: =========== Freelist and remote queue contained the SAME blocks, causing use-after-free: 1. Thread A (owner): pops block X from freelist → allocates to user 2. User writes data ("ab") to block X 3. Thread B (remote): free(block X) → adds to remote queue 4. Thread A (later): drains remote queue → *(void**)block_X = chain_head → OVERWRITES USER DATA! 💥 The freelist pop path did NOT drain the remote queue first, so blocks could be simultaneously in both freelist and remote queue. Fix: ==== Add remote queue drain BEFORE freelist pop in refill path: core/hakmem_tiny_refill_p0.inc.h: - Call _ss_remote_drain_to_freelist_unsafe() BEFORE trc_pop_from_freelist() - Add #include "superslab/superslab_inline.h" - This ensures freelist and remote queue are mutually exclusive Test Results: ============= BEFORE: larson_hakmem (4 threads): ❌ SEGV in seconds (freelist corruption) AFTER: larson_hakmem (4 threads): ✅ 931,629 ops/s (1073 sec stable run) bench_random_mixed: ✅ 1,020,163 ops/s (no crashes) Evidence: - Fail-Fast logs showed next pointer corruption: 0x...6261 (ASCII "ab") - Single-threaded benchmarks worked (865K ops/s) - Multi-threaded Larson crashed immediately - Fix eliminates all crashes in both benchmarks Files: - core/hakmem_tiny_refill_p0.inc.h: Add remote drain before freelist pop - CURRENT_TASK.md: Document fix details 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 01:35:45 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Timeline
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
- **Investigation**: Task Agent (Ultrathink mode)
- **Report Review**: 30 min
- **Implementation**: 1-2 days (depends on findings)
- **Validation**: Re-run benchmarks
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
---
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
## Notes
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
- Debug logs now properly guarded with `HAKMEM_SUPERSLAB_VERBOSE`
- Can be enabled with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging
- Release builds will be clean (no log spam)
Phase 7-1 PoC: Region-ID Direct Lookup (+39%~+436% improvement!) Implemented ultra-fast header-based free path that eliminates SuperSlab lookup bottleneck (100+ cycles → 5-10 cycles). ## Key Changes 1. **Smart Headers** (core/tiny_region_id.h): - 1-byte header before each allocation stores class_idx - Memory layout: [Header: 1B] [User data: N-1B] - Overhead: <2% average (0% for Slab[0] using wasted padding) 2. **Ultra-Fast Allocation** (core/tiny_alloc_fast.inc.h): - Write header at base: *base = class_idx - Return user pointer: base + 1 3. **Ultra-Fast Free** (core/tiny_free_fast_v2.inc.h): - Read class_idx from header (ptr-1): 2-3 cycles - Push base (ptr-1) to TLS freelist: 3-5 cycles - Total: 5-10 cycles (vs 500+ cycles current!) 4. **Free Path Integration** (core/box/hak_free_api.inc.h): - Removed SuperSlab lookup from fast path - Direct header validation (no lookup needed!) 5. **Size Class Adjustment** (core/hakmem_tiny.h): - Max tiny size: 1023B (was 1024B) - 1024B requests → Mid allocator fallback ## Performance Results | Size | Baseline | Phase 7 | Improvement | |------|----------|---------|-------------| | 128B | 1.22M | 6.54M | **+436%** 🚀 | | 512B | 1.22M | 1.70M | **+39%** | | 1023B | 1.22M | 1.92M | **+57%** | ## Build & Test Enable Phase 7: make HEADER_CLASSIDX=1 bench_random_mixed_hakmem Run benchmark: HAKMEM_TINY_USE_SUPERSLAB=1 ./bench_random_mixed_hakmem 10000 128 1234567 ## Known Issues - 1024B requests fallback to Mid allocator (by design) - Target 40-60M ops/s not yet reached (current: 1.7-6.5M) - Further optimization needed (TLS capacity tuning, refill optimization) ## Credits Design: ChatGPT Pro Ultrathink, Claude Code Implementation: Claude Code with Task Agent Ultrathink support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 03:18:17 +09:00
---
refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK ## Changes ### 1. Debug Log Cleanup (Release Build Optimization) **Files Modified:** - `core/tiny_superslab_alloc.inc.h:183-234` - `core/hakmem_tiny_superslab.c:567-618` **Problem:** - SuperSlab expansion logs flooded output (268+ lines per benchmark run) - Massive I/O overhead masked true performance in benchmarks - Production builds should not spam stderr **Solution:** - Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)` - Debug builds: Logs enabled by default - Release builds: Logs disabled (clean output) - Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging **Guarded Messages:** - "SuperSlab chunk exhausted for class X, expanding..." - "Successfully expanded SuperSlabHead for class X" - "CRITICAL: Failed to expand SuperSlabHead..." (OOM) - "Expanded SuperSlabHead for class X: N chunks now" **Impact:** - Release builds: Clean benchmark output (no log spam) - Debug builds: Full visibility into expansion behavior - Performance: No I/O overhead in production benchmarks ### 2. CURRENT_TASK.md Update **New Focus:** ACE Investigation for Mid-Large Performance Recovery **Context:** - ✅ 100% stability achieved (commit 616070cf7) - ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System) - 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System) - Root cause: ACE disabled → all allocations go to mmap (slow) **Next Task:** Task Agent to investigate ACE mechanism (Ultrathink mode): 1. Why is ACE disabled? 2. How does ACE improve Mid-Large performance? 3. Can we re-enable ACE to recover +171% advantage? 4. Implementation plan and risk assessment **Benchmark Results:** Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/` --- ## Testing Verified clean build output: ```bash make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem ./larson_hakmem 1 1 128 1024 1 12345 1 # No expansion log spam in release build ``` 🎉 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-08 22:02:09 +09:00
**Status**: Ready to launch Task Agent investigation 🚀