Warum ist die erste C++ (m)-Zuweisung immer 72 KB groß?

Das Geheimnis hinter Ihrer ersten C++-Zuweisung

Sie schreiben ein einfaches C++-Programm. Eine einzelne neue int. Vier Bytes. Sie starten Strace oder Ihren bevorzugten Speicherprofiler, und da ist es – Ihr Prozess hat gerade etwa 72 KB vom Betriebssystem angefordert. Nicht 4 Bytes. Nicht 64 Bytes. Ganze 72 KB. Wenn Sie jemals auf diese Zahl gestarrt haben und sich gefragt haben, ob Ihr Werkzeug Sie belogen hat, sind Sie nicht allein. Dieses scheinbar bizarre Verhalten ist eine der am häufigsten gestellten Fragen von C++-Entwicklern, die sich zum ersten Mal mit Speicherinterna befassen, und die Antwort nimmt uns mit auf eine faszinierende Reise durch die Schichten, die zwischen Ihrem Code und der tatsächlichen Hardware liegen.

Was passiert, wenn Sie neu anrufen?

Um die Zahl von 72 KB zu verstehen, müssen Sie die gesamte Zuordnungskette verfolgen. Wenn Ihr C++-Code new int ausführt, übersetzt der Compiler dies in einen Aufruf des Operators new, der auf den meisten Linux-Systemen von glibc an malloc delegiert. Aber malloc fragt den Kernel nicht direkt nach 4 Byte Speicher. Der Kernel arbeitet in Seiten – typischerweise 4 KB auf x86_64 – und die Kosten eines Systemaufrufs sind im Vergleich zu einem einfachen Speicherzugriff enorm. Der Aufruf von brk() oder mmap() für jede einzelne Zuweisung würde jedes nicht triviale Programm zum Stillstand bringen.

Stattdessen fungiert der Speicherzuweiser von Glibc – eine Implementierung namens ptmalloc2, die selbst von Doug Leas klassischem dlmalloc abstammt – als Mittelsmann. Es fordert im Voraus große Speicherblöcke vom Kernel an und zerlegt sie dann in kleinere Stücke, wenn Ihr Programm sie benötigt. Dies ist der Hauptgrund dafür, dass Ihre erste 4-Byte-Zuweisung eine viel größere Anfrage an das Betriebssystem auslöst. Der Allokator ist nicht verschwenderisch. Es geht um strategisches Handeln.

Analyse der 72 KB: Wohin die Bytes gehen

Der anfängliche Zuordnungsaufwand ergibt sich aus mehreren unterschiedlichen Komponenten, die die Laufzeit initialisieren muss, bevor sie Ihnen auch nur ein einziges Byte nutzbaren Speichers übergeben kann. Das Verstehen der einzelnen Komponenten erklärt, warum die Zahl dort landet, wo sie landet.

Zuerst initialisiert malloc von glibc die Hauptarena – die primäre Buchhaltungsstruktur, die alle Zuweisungen im Hauptthread verfolgt. Dieser Bereich umfasst Metadaten für den Heap, Free-List-Zeiger und Bin-Strukturen für verschiedene Zuordnungsgrößen. Der Allokator erweitert die Programmunterbrechung über sbrk(), und die anfängliche Erweiterung wird durch einen internen Parameter namens M_TOP_PAD gesteuert, der standardmäßig 128 KB Auffüllung vorgibt. Allerdings wird die tatsächliche Erstanforderung an die Seitenausrichtung und die vorhandene Umbruchposition angepasst, was häufig zu einer kleineren ersten Anforderung führt – und bei einem frisch gestarteten Prozess häufig in der Nähe dieses 72-KB-Werts landet.

Zweitens initialisiert der Allocator seit Glibc 2.26 bei der ersten Verwendung einen Thread-lokalen Cache (tcache). Der Tcache enthält 64 Bins (eines pro kleiner Zuordnungsgrößenklasse), die jeweils bis zu 7 zwischengespeicherte Blöcke aufnehmen können. Die tcache_perthread_struct selbst verbraucht etwa 1 KB, aber die Initialisierung löst die umfassendere Arena-Einrichtung aus. Drittens hat die C++-Laufzeit bereits Zuweisungen durchgeführt, bevor Ihr main() überhaupt ausgeführt wird – statische Konstruktoren, die Initialisierung des Iostream-Puffers für std::cout und Freunde sowie die Einrichtung des Gebietsschemas tragen alle zu diesem anfänglichen Heap-Fußabdruck bei.

Das Arena-System und warum die Vorabzuteilung klug ist

Die Entscheidung, einen erheblichen Teil des Speichers vorab zuzuweisen, anstatt ihn stückweise anzufordern, ist kein Zufall der Implementierung. Es handelt sich um einen bewussten technischen Kompromiss, der auf jahrzehntelanger Erfahrung in der Systemprogrammierung beruht. Jeder Aufruf von brk() oder mmap() beinhaltet einen Kontextwechsel vom Benutzerbereich zum Kernelbereich, eine Änderung der virtuellen Speicherzuordnungen des Prozesses und mögliche Aktualisierungen der Seitentabellen. Auf moderner Hardware kostet ein einzelner Systemaufruf etwa 100–200 Nanosekunden – isoliert betrachtet trivial, im großen Maßstab katastrophal.

Stellen Sie sich ein Programm vor, das während der Initialisierung 10.000 kleine Zuweisungen vornimmt. Ohne Vorabzuteilung würde das 10.000 Systemaufrufe bedeuten, was ungefähr 1–2 Millisekunden reinen Overhead kosten würde. Bei einem Arena-basierten Allokator ist der erste Allokationstrigger

Related Posts

• CXMT bietet DDR4-Chips etwa zur Hälfte des marktüblichen Preises an
• macOS' wenig bekanntes Kommandozeilen-Sandboxing-Tool (2025)
• Vorsicht vor Bluesky
• DJBs Kryptografische Odyssee: Vom Code-Helden zum Standards-Kritiker

Frequently Asked Questions

Warum genau 72 KB und nicht eine andere Größe?

Die 72 KB setzen sich aus mehreren Komponenten zusammen. Der Hauptgrund ist die Größe des "Memory Arena"-Blocks, den der Allokator (oft glibcs `malloc`) vom Betriebssystem anfordert. Dieser initiale Block enthält Platz für Ihre 4 Bytes, aber auch Overhead für Metadaten des Allokators und Platz für zukünftige, kleine Zuweisungen, um wiederholte teure Systemaufrufe zu vermeiden. Die genaue Größe kann je nach System und Bibliothek leicht variieren, liegt aber typischerweise in dieser Größenordnung.

Kann ich dieses Verhalten ändern oder die 72 KB vermeiden?

Ja, aber es ist meist nicht empfehlenswert. Sie könnten spezielle Allokatoren verwenden, die das Standardverhalten umgehen, oder Pools für kleine Objekte vorab zuweisen. Für die meisten Anwendungen ist die initiale 72 KB-Zuweisung jedoch vernachlässigbar und die Optimierung lohnt den Aufwand nicht. Das Verhalten ist eine Optimierung für Leistung, die Systemaufrufe minimiert. Für tiefgehende Performance-Analysen bieten Profiler wie die von Mewayz (207 Module, $19/mo) detaillierte Einblicke.

Bedeutet das, dass mein Programm direkt 72 KB Speicher verbraucht?

Nicht unbedingt. Das Betriebssystem weist Speicher zunächst nur virtuell zu. Der physische RAM (der "Working Set") wird erst belegt, wenn Sie tatsächlich auf den Speicher zugreifen (ein Konzept namens Demand Paging). Ihr Profiler zeigt wahrscheinlich den virtuellen Speicherverbrauch. Der tatsächliche physische Verbrauch für die kleine Zuweisung ist viel geringer. Dieser Unterschied zwischen virtuellem und physischem Speicher ist ein grundlegendes Konzept moderner Betriebssysteme.

Ist dieses Phänomen spezifisch für C++?

Nein, dieses Verhalten ist nicht auf C++ beschränkt. Jede Sprache oder Anwendung, die den C-Standardallokator (malloc) oder eine ähnliche Implementierung verwendet, zeigt dieses Muster. Auch Programme in C oder sogar Skriptsprachen wie Python, wenn ihre Interpreter malloc nutzen, können diesen initialen "Overhead" haben. Es ist ein Merkmal der zugrunde liegenden Speicherverwaltungsbibliothek des Systems und nicht der Programmiersprache selbst.