Observed Signal · Jun 18, 2026 · Technical Release · Source: DEV Community · Impact: 2/5 · Sentiment: Neutral
PMAD: Deleting malloc's slow path for deterministic allocation
An author published PMAD, a small open-source C99 allocator that removes the traditional “slow path” from malloc-style allocators to bound per-call latency. Benchmarks (macOS) show typical median allocations are nanoseconds while rare slow-path hits in system allocators produced single malloc calls as high as ~7 milliseconds. PMAD instead mmaps a fixed pool at startup, requires declared size classes, and implements alloc/free as O(1) free-list operations with no fallback, coalescing, growth, or locks. In head-to-head tests PMAD keeps the tail latency tight (P50→P99.9 spreads small) and under sustained fragmenting churn its worst case held around 40 µs versus the system allocator’s ~6.95 ms. PMAD is MIT-licensed, available on GitHub, targeted at special-purpose, per-core shared-nothing systems, and the published benchmarks are macOS-only.
An open-source deterministic allocator matters to engineers building low-latency, real-time systems (including some AdTech use cases), but it is a special-purpose project with macOS-only published benchmarks and limited immediate industry-wide impact.
Track GitHub Signals & Market Shifts in Real-Time
Polaris7 autonomous intelligence agents track regulatory filings, primary sources, executive changes, and deal flow 24/7. Create your free Explorer workspace to monitor these entities.
Key Takeaways & Evidence Grounding
- Author measured a single malloc worst-case of 6,950,000 ns (≈7 ms) while median calls were ~16 ns.
- PMAD eliminates the allocator slow path by mmap-ing a fixed pool at startup and using predeclared block classes.
- Alloc and free are O(1) operations (lookup-table index + free-list pop / header read + push) with no locks or fallback.
- In benchmarks (macOS) PMAD showed a flat tail (P50 2.59 → P99.9 6.50) and under sustained churn a worst case of ~40 µs, ~174× tighter than the system allocator.
- PMAD is open-source (MIT, C99) and available at https://github.com/anastassow/PMAD; tests are reproducible from the repo.
Connected Companies & Entities
1 Entity mappedOntology Mapping & Concepts
Related Market Signals & Shifts
Recent verified developments and strategic activity across this market segment.
10-Minute Guard Reclaims 46GB Compressed Memory Leak
A developer discovered a macOS blind spot where compressed memory (CMPRS) is not counted in RSS, allowing the system daemon dasd to accumulate 46GB of compressed memory while reporting only 264MB RSS. The leak caused swap to balloon (≈37GB), which made Playwright operations time out and halted an automated social-posting environment. The author implemented mem-hog-guard.sh — a launchd-scheduled script running every 10 minutes that reads top's MEM (which includes CMPRS), converts units to MB, applies per-process thresholds and cooldown files, and restarts processes differently depending on whether they are system daemons or user launchd jobs. The script uses locking, DRY_RUN checks, PATH tightening for launchd, and sends aggregated Discord notifications. On the observed run the guard reclaimed dasd (logged at 02:32) and swap dropped to 4.1GB.
Dedicated macOS CI runners benchmarked faster than GitHub-hosted
This article presents a benchmark comparing dedicated macOS runners from Manzanita against GitHub-hosted macOS runners across five open-source projects. The author, who works on Manzanita, forked the projects and changed only the runner label. Results show significant speedups for simulator-heavy iOS tests and clean compiles, with up to 4.74x faster build steps. However, short jobs dominated by cache I/O could be slower, and projects requiring non-Apple toolchains or specific Xcode versions may not benefit. The article also mentions a flat monthly pricing model for dedicated runners.
GC Tuning Broke Leaderboard; Rust Fix Restored Latency
A developer recounts a production incident where Go's garbage collector caused severe P99 latency spikes on an in-memory leaderboard (400k rows, 40 MB/s write throughput). GC tuning flags (GOGC, GOMEMLIMIT, runtime.SetGCPercent) either removed pauses or caused RSS growth and OOMs due to per-row 256-byte allocation churn. The team rewrote the leaderboard core in Rust (1.75-nightly) with jemalloc and a pre-allocated 2 MB bump allocator, eliminating per-update allocations and reducing cache misses. Post-migration metrics under the same load: P99 fell from 112 ms to 6 ms, RSS dropped from 11 GB to 2.1 GB, and allocation counts fell dramatically. The Go tier remained for API routing; writes use gRPC to Rust with a circuit breaker that reroutes to a Redis fallback queue when the arena fills.
Track Real-Time Market Signals & Shifts
Set up custom watchlists to receive automated, evidence-grounded executive digests whenever material signals or shifts occur across your tracked landscape.