Was malloc wirklich macht – und warum es 22-mal schneller ist als ein Syscall
What is malloc doing, anyway?
malloc sieht simpel aus, doch hinter dem void-Pointer steckt Buchhaltung: glibc fordert per brk große Blöcke vom Kernel und verteilt sie selbst in Chunks mit Größenkopf. Ein eigener Bump-Allocator zeigt, warum das nötig ist – malloc(16) braucht 26,9 ns, sbrk(16) dagegen 610 ns. Schritt für Schritt entsteht ein Allocator mit Free-List, Splitting, Coalescing, Demand Paging und trim, der Speicher auch wieder an den Kernel zurückgibt.
Jeder Prozess sieht virtuellen Speicher, den der Kernel in 4-KiB-Seiten auf physischen RAM abbildet – eine virtuelle Seite braucht erst bei ihrem ersten Schreibzugriff physischen Speicher dahinter.
- assumed_throwaw
Etwas abseits vom Thema, aber die Komplexität und der Overhead der malloc-Abstraktion sind genau das, was mich sehr für „stack-only“-Sprachen wie das kürzlich veröffentlichte Goose begeistert hat. Es hat etwas sehr Elegantes und Aufregendes, die Idee, sie (fast) vollständig loszuwerden. So wie moderne Programmiersprachen eine gute Ergonomie entwickelt haben, die einen Garbage Collector ersetzt, könnte man das hoffentlich auch für heap-allokierten Speicher schaffen.
- K0IN
Als ich mit wasm anfing, als es neu war und clang-Unterstützung hatte, schrieb ich meine eigene libc und malloc, was eine so großartige Lernerfahrung war – all diese Low-Level-Funktionen und Tricks (freie Listen zum Beispiel). Ich mag auch, dass ich wasm ziemlich gut lesen kann, und die Tooling ist gut, um einfach eine .wat zurückzugeben und sie zu lesen.
- projectileboy
Gute Lernressource für dieses (und verwandte) Themen: https://cs61.seas.harvard.edu/site/2026/
- bajard
Malloc() ist laaangsam. Noch mehr, wenn man auch free() verwendet. Erwäge, ein einzelnes Array zu allokieren und dort zu arbeiten, wenn möglich.
- wpmaven
Ich fand dieses hier vor einiger Zeit sehr gut erklärt, für diejenigen, die mehr Details suchen: https://sploitfun.wordpress.com/2015/02/10/understanding-gli...