Expand description
The per-shard heap.
§Why there is no thread-local cache in front of this
tcmalloc and mimalloc put a thread cache ahead of a shared central heap because they cannot know how threads relate to memory, and torajs-mmalloc’s finding doc records what happens without one: its first cutover cost 10–30 ns per allocation and reversed alloc-heavy benchmarks by up to 4×, until a TLAB went in front.
kevy pins a shard per core and routes every key to its owner, so the heap is the thread-local structure. The fast path pops from the current span’s free list with no atomics — which is what a thread cache exists to achieve. Adding one here would put a cache in front of a cache. This is the divergence from the references that ROADMAP rule ② asks to be stated rather than assumed.
Cross-shard frees are real (values travel on the shared read lane),
and they are handled by [segment::push_foreign] — push-only, so
there is no ABA hazard to inherit.
Structs§
- Heap
- One shard’s heap. Not
Sync: exactly one thread owns it, which is what removes the atomics from the fast path.
Constants§
- EMPTY_
SPAN_ HYSTERESIS - Empty spans a heap keeps mapped-but-discarded before releasing the whole segment. Decay-style hysteresis, after jemalloc: releasing eagerly turns a churny workload into an mmap/munmap storm.
- PER_
CLASS_ CAP - Spans one class may hold at once, per heap — a runaway guard, not a policy. At 64 KiB a span, this bounds one class at roughly 4 GiB per shard, which no correct program reaches by accident.