Beobachtetes Signal · 18. Juni 2026 · Technical Release · Quelle: DEV Community · Relevanz: 2/5 · Sentiment: Neutral
PMAD: Entfernung des Malloc-Slow-Paths für deterministische Speicherallokation
Ein Entwickler hat PMAD veröffentlicht, einen kompakten Open-Source-C99-Allokator, der den traditionellen Slow-Path von Malloc-basierten Allokatoren entfernt, um die Latenz pro Aufruf zu begrenzen. Benchmarks unter macOS zeigen, dass typische Median-Allokationen im Nanosekundenbereich liegen, während seltene Slow-Path-Treffer bei Systemallokationen einzelne Malloc-Aufrufe von bis zu rund 7 Millisekunden verursachten. Stattdessen mmap-t PMAD beim Start einen festen Pool, erfordert deklarierte Grössenklassen und implementiert Alloc/Free als O(1)-Free-List-Operationen ohne Fallback, Coalescing, Wachstum oder Locks. In direkten Tests hält PMAD die Tail-Latency gering (geringe P50-zu-P99.9-Spannen), und unter anhaltender Fragmentierungs-Churn lag der Worst-Case bei rund 40 µs im Vergleich zu ca. 6,95 ms des Systemallokators. PMAD steht unter MIT-Lizenz auf GitHub zur Verfügung, zielt auf spezialisierte, Per-Core Shared-Nothing-Systeme ab, und die veröffentlichten Benchmarks beschränken sich auf macOS.
Ein Open-Source-Allokator für deterministisches Verhalten ist für Ingenieure von Bedeutung, die Latenz-kritische Echtzeitsysteme entwickeln (darunter auch bestimmte Use Cases in AdTech). Es handelt sich jedoch um ein spezialisiertes Projekt mit macOS-exklusiven Benchmarks und begrenztem unmittelbaren Brancheneinfluss.
Marktsignale zu GitHub in Echtzeit verfolgen
Polaris7 erfasst behördliche Registrierungen, Primärquellen, Führungswechsel und Deal-Aktivitäten rund um die Uhr. Erstellen Sie Ihren kostenlosen Explorer-Workspace, um automatisierte Executive Briefings zu erhalten.
Wichtigste Kernpunkte & Evidenz
- Der Autor hat einen Malloc-Worst-Case von 6.950.000 ns (ca. 7 ms) gemessen, während die Median-Aufrufe bei ca. 16 ns lagen.
- PMAD eliminiert den Allocator-Slow-Path durch das mmap-en eines festen Pools beim Start und die Nutzung vorab deklarierter Blockklassen.
- Alloc und Free sind O(1)-Operationen (Lookup-Table-Index plus Free-List-Pop bzw. Header-Read plus Push) ohne Locks oder Fallback.
- In Benchmarks unter macOS zeigte PMAD eine flache Tail-Latency (P50 2,59 bis P99.9 6,50) und unter anhaltender Churn einen Worst-Case von ca. 40 µs (ca. 174-mal enger als der Systemallokator).
- PMAD ist Open-Source (MIT, C99) unter https://github.com/anastassow/PMAD verfügbar; Tests sind aus dem Repository reproduzierbar.
Verknüpfte Unternehmen
1 verknüpfte UnternehmenOntologie & Marktkonzepte
Verwandte Marktsignale & Trends
Aktuelle verifizierte Unternehmensentwicklungen und Deal-Aktivitäten in diesem Marktsegment.
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.
Dedizierte macOS-CI-Runner übertreffen GitHub-hosted-Instanzen im Benchmark
Ein aktueller Benchmark vergleicht dedizierte macOS-Runner des Anbieters Manzanita mit GitHub-hosted macOS-Runnern anhand von fünf Open-Source-Projekten. Der Testaufbau basierte auf identischen Repositories, bei denen lediglich das Runner-Label angepasst wurde. Die Ergebnisse belegen signifikante Performance-Gewinne, insbesondere bei simulatorintensiven iOS-Tests und Clean Builds, mit bis zu 4,74-mal schnelleren Build-Schritten. Beispielsweise verkürzte sich der iOS-Test-Job von 'argmax-oss-swift' um das 3,13-Fache von rund 26 auf etwa 8 Minuten. Kürzere CI-Jobs, die stark von Cache-I/O dominiert werden, schnitten auf den dedizierten Instanzen hingegen teils langsamer ab. Zudem profitieren Projekte, die spezifische Xcode-Versionen oder Non-Apple-Toolchains erfordern, unter Umständen weniger. Neben der reinen Rechenleistung thematisiert der Bericht auch das Pauschalpreismodell (Flat-Monthly-Pricing) für dedizierte Runner-Infrastruktur als potenziellen Kostenvorteil.
GC-Tuning führt zu Latenzspitzen: Rust-Migration rettet In-Memory-Leaderboard
Ein Entwicklerbericht schildert einen Produktionsvorfall, bei dem der Garbage Collector von Go massive P99-Latenzspitzen auf einem In-Memory-Leaderboard mit 400.000 Zeilen und 40 MB/s Schreibdurchsatz auslöste. GC-Tuning-Parameter wie GOGC, GOMEMLIMIT und runtime.SetGCPercent beseitigten entweder die Pausen nicht oder führten aufgrund von Allokationsspitzen zu starkem RSS-Wachstum und OOM-Abstürzen. Das Team schrieb den Kern des Leaderboards in Rust unter Verwendung von jemalloc und einem vorallokierten Bump-Allocator neu, wodurch pro Update keine Allokationen mehr anfielen und Cache-Misses reduziert wurden. Unter identischer Last sank die P99-Latenz von 112 ms auf 6 ms, während der RSS-Speicherbedarf von 11 GB auf 2,1 GB zurückging. Die Go-Schicht blieb für das API-Routing erhalten; Schreibvorgänge nutzen gRPC mit einem Circuit Breaker und einer Redis-Fallback-Queue.
Marktsignale & Strategische Shifts in Echtzeit verfolgen
Erstellen Sie benutzerdefinierte Watchlists, um automatisierte, evidenzbasierte Executive Briefings zu erhalten, sobald wesentliche Signale oder Marktverschiebungen auftreten.