Dennis Ritchie versteckte in Unix V4 ein malloc, das moderne Heap-Bugs verhindern könnte
The lost malloc()
In den Quellen von Unix V4 von 1973 stößt der Autor auf Dennis Ritchie's malloc.c: Statt eines globalen Heaps arbeitet malloc() dort auf expliziten Speicherregionen (coremap, swapmap), und mfree() bekommt die Größe des Objekts mit. Das Interface erlaubt es, ganze Regionen zu verwerfen, Speicher zu partitionieren und Fremdcode hart zu begrenzen – Vorteile, die modernes malloc()/free() nicht bietet. Später setzte sich die traditionelle Variante durch, vermutlich aus Hardware-Gründen.
Diese sind mit der Zuteilung und späteren Freigabe zweier Arten von Speicherressourcen befasst, nämlich: Hauptspeicher in Einheiten von 32 Wörtern (64 Bytes); Disk-Swap-Bereich in Einheiten von 256 Wörtern (512 Bytes).
- adrian_b
Der Autor hat nicht wirklich herausgefunden, woher SIMULA 67 das „new“ genommen hat.
Im November 1965 veröffentlichte C.A.R. Hoare einen äußerst einflussreichen Artikel: „Record Handling“. Dies war eine vorgeschlagene Erweiterung für den Nachfolger von ALGOL 60.
Fast alle Funktionen, die in SIMULA 67 gegenüber seinem Vorgänger, der Sprache SIMULA, hinzugefügt wurden, stammen direkt aus dem Artikel von Hoare, mit zwei großen Ausnahmen: Klassenvererbung und die „virtuellen“ Prozeduren, die von den SIMULA 67-Erfindern (Kristen Nygaard & Ole-Johan Dahl) erfunden wurden und die für die objektorientierte Programmierung wesentlich sind.
Die SIMULA 67-Schlüsselwörter „class“ und „new“ wurden aus Hoares Artikel übernommen (Hoare hatte „class“ tatsächlich aus COBOL 60 übernommen, das im Vergleich zu ALGOL 60 eine ganz andere Terminologie verwendete, wobei eine der vielen Unterschiede die Verwendung von „class“ anstelle des von ALGOL 60 verwendeten „type“ war).
Hoares Artikel diskutierte eine Vielzahl von Programmiersprachenfunktionen, von denen die meisten neu waren, darunter die Definition strukturierter Typen mit Konstruktoren und Destruktoren, diskriminierte Unions (von John McCarthy übernommen), Aufzählungen, der NULL-Zeiger und viele andere.
SIMULA 67 war eine der ersten Sprachen, die viele der von Hoare vorgeschlagenen Funktionen implementierte. Andere Sprachen, die einige der vorgeschlagenen Funktionen implementierten, waren IBM PL/I, ALGOL 68, dann ein paar Jahre später, im November 1970, Pascal.
Das Schlüsselwort „new“ war bereits zum ersten Mal von Niklaus Wirth verwendet worden, aber bei Wirth hatte es eine andere Bedeutung als bei Hoare. Es deklarierte eine Variable […]
- OskarS
> Nicht nur das, mfree() erhält die Größe des Objekts, das es freigibt, wie es sein sollte.
Ich habe immer gedacht, dass dies einer der größten kleinen Fehler in der Geschichte dieser Branche ist. Es bedeutet mehr oder weniger, dass man den Speicherallokator dazu zwingt, diese Größen im Auge zu behalten, obwohl er das nicht müsste. Es gibt praktisch keinen vernünftigen Fall, in dem die Person, die free() aufruft, nicht die Größe der Allokation kennt, also führen wir diese Buchhaltung jetzt doppelt, im „User-Space“ und innerhalb des Speicherallokators. Denk mal an die Fälle, in denen man malloc aufruft:
* Für die Allokation eines einzelnen Objekts vom Typ T ist die Größe einfach `sizeof(T)`, man kann sie also einfach an free() übergeben.
* Für die Allokation eines Arrays von Objekten ist die Größe `count * sizeof(T)`, und mir fällt kein einziges Mal ein, wo man NICHT weiß, was `count` ist. Entweder ist es statisch dimensioniert (dann ist es einfach eine Konstante), oder wenn man ein dynamisch wachsendes Array hat, muss man den reservierten Platz im Auge behalten, um zu wissen, wann man reallokiert. Wenn sonst nichts, braucht man es für die Bereichsprüfung.
* Für Blöcke rohen Speichers weiß man vermutlich beim Freigeben auch, wie groß der rohe Speicher ist, den man allokiert hat, aus denselben Gründen wie im vorherigen Punkt. Einfach einen rohen char*-Zeiger ohne Größeninformation herumliegen zu lassen, ist einfach schreckliche C-Praxis.
Wenn man die Größe seiner Allokation wirklich nicht kennt (sehr schwer vorstellbar, wann das jemals passieren sollte), sollte man gezwungen sein, sie auf der Benutzerseite irgendwie im Auge zu behalten, und nicht […]
- veltas
Ich identifiziere mich hier nicht so gut mit dem Autor, weil ich von ‚Arena-Allokatoren‘ nicht begeistert bin und es mir eigentlich egal ist, dass free keine Größe erhält. Ich denke, die Schnittstelle war in Ordnung.
Außerdem sind ‚Arena-Allokatoren‘ (das bedeutete vor etwa 20 Jahren etwas anderes, also wurde der Name wohl einfach umbenannt) nicht so gut, sie machen manche Dinge einfacher und verbessern manchmal die Leistung, sie neigen aber auch dazu, mehr Speicher zu verbrauchen und Fragmentierung zu verursachen, wenn sie nicht sorgfältig verwendet werden. Das ist einer der vielen Gründe, warum wir uns langsam von den alten linearen Allokatoren entfernt haben, aber auch, weil wir einfach eine einfache und flexible Schnittstelle wollten, um Komplexität zu verbergen.
- fjfaase
Der sbrk-Systemaufruf in Linux ist immer noch verfügbar, um mehr Heap vom Betriebssystem zu bekommen. Speicher wird also immer noch linear allokiert und nie wieder freigegeben. Vielleicht ändern Funktionen wie mmap das jetzt. Ich habe sbrk verwendet, um malloc für eine sehr eingeschränkte Standardbibliotheksimplementierung zu implementieren.
- jdw64
Als ich Student war (vor 15 Jahren), bin ich zum ersten Mal durch „A Book on C“ mit C in Berührung gekommen, und C scheint eine Sprache zu sein, die einfach ist, aber wirklich viel leisten kann. Wenn man sieht, wie alt diese Sprache ist und wie viele Konzepte, die in modernen Sprachen bereits verwendet werden, während ihrer Entwicklungsgeschichte ausprobiert wurden, ist das überraschend. Es ist überraschend, dass die Konzepte, die ich für moderne Techniken von heute hielt, schon vor Jahrzehnten ausprobiert wurden – also bevor ich überhaupt geboren wurde.
Es ist erstaunlich, dass eine Methode wie der Bump Allocator bereits ausprobiert wurde.
Wie konnten die erfahrenen Programmierer das alles schaffen? Ich bin einfach erstaunt.