Warum überhaupt brk in malloc verwenden? Warum nicht einfach mmap verwenden?

Typische Implementierungen von malloc verwenden brk/sbrk als primäres Mittel, um Speicher vom Betriebssystem zu beanspruchen. Allerdings verwenden sie auch mmap um Chunks für große Allokationen zu erhalten. Gibt es einen echten Vorteil für die Verwendung brk Anstatt von mmap, oder ist es nur Tradition? Würde es nicht genauso gut funktionieren, alles damit zu machen mmap?

(Hinweis: Ich benutze sbrk und brk hier austauschbar, da es sich um Schnittstellen zum gleichen Linux-Systemaufruf handelt, brk.)

Als Referenz finden Sie hier einige Dokumente, die die glibc beschreiben malloc:

Referenzhandbuch zur GNU-C-Bibliothek: Der GNU-Zuordner
https://www.gnu.org/software/libc/manual/html_node/The-GNU-Allocator.html

glibc-Wiki: Überblick über Malloc
https://sourceware.org/glibc/wiki/MallocInternals

Was diese Dokumente beschreiben, ist das sbrk wird verwendet, um eine primäre Arena für kleine Zuteilungen zu beanspruchen, mmap wird verwendet, um sekundäre Arenen zu beanspruchen, und mmap wird auch verwendet, um Platz für große Objekte zu beanspruchen (“viel größer als eine Seite”).

Die Verwendung sowohl des Anwendungsheaps (beansprucht mit sbrk) und mmap führt einige zusätzliche Komplexität ein, die unnötig sein könnte:

Zugewiesene Arena – Die Hauptarena verwendet den Heap der Anwendung. Andere Arenen verwenden mmap‘d haufenweise. Um einen Chunk einem Heap zuzuordnen, müssen Sie wissen, welcher Fall zutrifft. Wenn dieses Bit 0 ist, kommt der Chunk aus der Hauptarena und dem Haupthaufen. Wenn dieses Bit 1 ist, stammt der Chunk mmap‘d-Speicher und der Ort des Heaps können aus der Adresse des Chunks berechnet werden.

[Glibc malloc is derived from ptmalloc, which was derived from dlmalloc, which was started in 1987.]

Das jemalloc manpage (http://jemalloc.net/jemalloc.3.html) hat folgendes zu sagen:

Traditionell wurden Allokatoren verwendet sbrk(2) um Speicher zu erhalten, der aus mehreren Gründen suboptimal ist, einschließlich Rennbedingungen, erhöhter Fragmentierung und künstlichen Beschränkungen des maximal nutzbaren Speichers. Wenn sbrk(2) vom Betriebssystem unterstützt wird, verwendet diese Zuweisung beide mmap(2) und sbrk(2) in dieser bevorzugten Reihenfolge; sonst nur mmap(2) wird genutzt.

Also, das sagen sie hier sogar sbrk ist suboptimal, aber sie verwenden es trotzdem, obwohl sie sich bereits die Mühe gemacht haben, ihren Code so zu schreiben, dass er ohne es funktioniert.

[Writing of jemalloc started in 2005.]

UPDATE: Wenn ich mehr darüber nachdenke, gibt mir das bisschen über “in der Reihenfolge der Präferenz” eine Zeile auf Anfrage. Warum die Präferenzordnung? Benutzen sie nur sbrk als Fallback für den Fall mmap wird nicht unterstützt (oder es fehlen die erforderlichen Funktionen), oder es ist möglich, dass der Prozess in einen Zustand gelangt, in dem er verwendet werden kann sbrk aber nicht mmap? Ich werde mir ihren Code ansehen und sehen, ob ich herausfinden kann, was er tut.

Ich frage, weil ich ein Garbage-Collection-System in C implementiere und bisher keinen Grund sehe, etwas anderes zu verwenden mmap. Ich frage mich jedoch, ob ich etwas übersehe.

(In meinem Fall habe ich einen zusätzlichen Grund zu vermeiden brkdie ich möglicherweise verwenden muss malloc irgendwann.)

Der Systemaufruf brk() hat den Vorteil, nur ein einziges Datenelement zu haben, um die Speichernutzung zu verfolgen, was glücklicherweise auch direkt mit der Gesamtgröße des Heaps zusammenhängt.

Dies ist seit Unix V6 von 1975 in genau derselben Form der Fall. Wohlgemerkt, V6 unterstützte einen Benutzeradressraum von 65.535 Bytes. Es wurde also nicht viel darüber nachgedacht, viel mehr als 64 KB zu verwalten, sicherlich nicht Terabyte.

Verwenden mmap scheint vernünftig, bis ich mich frage, wie eine geänderte oder hinzugefügte Garbage Collection verwendet werden könnte mmmap aber ohne Umschreiben des Zuordnungsalgorithmus auch.

Funktioniert das gut mit realloc(), fork()etc.?

mmap() gab es in den frühen Versionen von Unix nicht. brk() war damals die einzige Möglichkeit, das Datensegment des Prozesses zu vergrößern. Die erste Version von Unix mit mmap() war SunOS Mitte der 80er Jahre war die erste Open-Source-Version 1990 BSD-Reno.

Und verwendbar sein für malloc() Sie möchten keine echte Datei zum Sichern des Speichers benötigen. 1988 wurde SunOS implementiert /dev/zero zu diesem Zweck und in den 1990er Jahren implementierte HP-UX die MAP_ANONYMOUS Flagge.

Mittlerweile gibt es Versionen von mmap() die eine Vielzahl von Methoden zur Zuweisung des Heaps bieten.

Berufung mmap(2) einmal pro Speicherzuweisung ist kein praktikabler Ansatz für einen Allzweck-Speicherzuordner, da die Zuweisungsgranularität (die kleinste einzelne Einheit, die gleichzeitig zugewiesen werden kann) für mmap(2) ist PAGESIZE (normalerweise 4096 Bytes) und weil es einen langsamen und komplizierten Systemaufruf erfordert. Der Allocator Fast Path für kleine Allokationen mit geringer Fragmentierung sollte keine Syscalls erfordern.

Unabhängig davon, welche Strategie Sie verwenden, müssen Sie immer noch mehrere der von Glibc als Speicherbereiche bezeichneten Bereiche und unterstützen das GNU-Handbuch erwähnt: “Das Vorhandensein mehrerer Bereiche ermöglicht es mehreren Threads, Speicher gleichzeitig in separaten Bereichen zuzuweisen, wodurch die Leistung verbessert wird.”

Die jemalloc-Manpage (http://jemalloc.net/jemalloc.3.html) hat folgendes zu sagen:

Traditionell haben Zuordner sbrk(2) verwendet, um Speicher zu erhalten, der aus mehreren Gründen suboptimal ist, darunter Race Conditions, erhöhte Fragmentierung und künstliche Beschränkungen des maximal nutzbaren Speichers. Wenn sbrk(2) vom Betriebssystem unterstützt wird, verwendet dieser Zuordner sowohl mmap(2) als auch sbrk(2) in dieser bevorzugten Reihenfolge; ansonsten wird nur mmap(2) verwendet.

Ich sehe nicht, wie irgendetwas davon auf die moderne Verwendung von zutrifft sbrk(2), so wie ich es verstehe. Race-Conditions werden durch Threading-Primitive behandelt. Die Fragmentierung wird genauso gehandhabt, wie dies bei von zugewiesenen Speicherbereichen der Fall wäre mmap(2). Der maximal nutzbare Speicher ist unerheblich, weil mmap(2) sollte für jede große Zuordnung verwendet werden, um die Fragmentierung zu reduzieren und den Speicher sofort wieder für das Betriebssystem freizugeben free(3).

Die Verwendung sowohl des Anwendungsheaps (beansprucht mit sbrk) als auch von mmap führt zu einer zusätzlichen Komplexität, die möglicherweise unnötig ist:

Zugewiesene Arena – Die Hauptarena verwendet den Heap der Anwendung. Andere Arenen verwenden Mmap-Haufen. Um einen Chunk einem Heap zuzuordnen, müssen Sie wissen, welcher Fall zutrifft. Wenn dieses Bit 0 ist, kommt der Chunk aus der Hauptarena und dem Haupthaufen. Wenn dieses Bit 1 ist, kommt der Chunk aus mmap-Speicher und der Ort des Heaps kann aus der Adresse des Chunks berechnet werden.

Die Frage ist nun, ob wir bereits verwenden mmap(2)warum nicht einfach eine Arena zu Beginn des Prozesses zuweisen mmap(2) statt zu verwenden sbrk(2)? Insbesondere dann, wenn, wie zitiert, nachvollzogen werden muss, welche Allokationsart verwendet wurde. Es gibt verschiedene Gründe:

1. mmap(2) möglicherweise nicht unterstützt.
2. sbrk(2) bereits für einen Prozess initialisiert ist, wohingegen mmap(2) würde zusätzliche Anforderungen einführen.
3. Wie glibc-Wiki sagt, “Wenn die Anfrage groß genug ist, wird mmap() verwendet, um Speicher direkt vom Betriebssystem anzufordern […] und es kann eine Grenze dafür geben, wie viele solcher Zuordnungen gleichzeitig vorhanden sein können. “
4. Eine Speicherkarte mit zugeordnet mmap(2) nicht so einfach erweiterbar. Linux hat mremap(2), aber seine Verwendung beschränkt den Zuordner auf Kernel, die ihn unterstützen. Premapping vieler Seiten mit PROT_NONE access verwendet zu viel virtuellen Speicher. Verwenden MMAP_FIXED löscht jede Zuordnung, die möglicherweise zuvor ohne Warnung vorhanden war. sbrk(2) hat keines dieser Probleme und ist explizit so konzipiert, dass der Speicher sicher erweitert werden kann.

Der offensichtliche Vorteil ist, dass Sie die letzte Zuteilung wachsen lassen können an Ort und Stellewas man damit nicht machen kann mmap(2) (mremap(2) ist eine Linux-Erweiterung, nicht portabel).

Für naive (und nicht so naive) Programme, die verwenden realloc(3) z.B. An einen String anzuhängen bedeutet dies einen Geschwindigkeitsschub von 1 oder 2 Größenordnungen 😉

Ich kenne die Details speziell für Linux nicht, aber unter FreeBSD wird seit einigen Jahren mmap bevorzugt und jemalloc in FreeBSDs libc hat sbrk() vollständig deaktiviert. brk()/sbrk() sind im Kernel auf den neueren Portierungen auf aarch64 und risc-v nicht implementiert.

Wenn ich die Geschichte von jemalloc richtig verstehe, war es ursprünglich der neue Allocator in FreeBSDs libc, bevor es ausgebrochen und portabel gemacht wurde. Jetzt ist FreeBSD ein nachgeschalteter Konsument von jemalloc. Es ist sehr wahrscheinlich, dass seine Präferenz für mmap() gegenüber sbrk() auf die Eigenschaften des FreeBSD-VM-Systems zurückzuführen ist, das um die Implementierung der mmap-Schnittstelle herum aufgebaut wurde.

Es ist erwähnenswert in SUS und POSIX brk/sbrk sind veraltet und sollten an dieser Stelle als nicht portierbar betrachtet werden. Wenn Sie an einer neuen Zuweisung arbeiten, möchten Sie sich wahrscheinlich nicht darauf verlassen.