Speicherverwaltung ein fall für die Engine?

[Lynxeye]

Nö. Aber von 8 TiB virtuellem Adressraum schon.

Das kann aber auch mal in die Hose gehen, wenn du nur noch <= 4GB auf der Festplatte frei hast. Sowas soll vorkommen. Irgendwo ist immer mal die Grenze. Und 64Bit hat auch nicht jeder (mich eingeschlossen).

Nein, kann es nicht. Niemand spricht davon, dass mehr Allokationen durchgeführt werden, als RAM vorhanden ist. Wenn wir von Adressraum verschwenden reden, meinen wir Adressen, die nicht mehr zu gebrauchen sind, zB halt durch Fragmentierung. Wenn ich diese Adressen nicht mehr gebrauchen kann, kann ich auch keine Allokationen dort durchführen. Ich kann also sehrwohl 2TB unnutzbar gewordenen Adressraum haben und dabei nur 10MB an RAM wirklich verbrauchen.

Und zu 32Bit: das zähle ich mal als PP. Ich jedenfalls weigere mich in meiner Freizeit über die Probleme der x86_32 Welt nachzudenken.

[BeRsErKeR]

Nö. Aber von 8 TiB virtuellem Adressraum schon.

Das kann aber auch mal in die Hose gehen, wenn du nur noch <= 4GB auf der Festplatte frei hast. Sowas soll vorkommen. Irgendwo ist immer mal die Grenze. Und 64Bit hat auch nicht jeder (mich eingeschlossen).

Nein, kann es nicht. Niemand spricht davon, dass mehr Allokationen durchgeführt werden, als RAM vorhanden ist. Wenn wir von Adressraum verschwenden reden, meinen wir Adressen, die nicht mehr zu gebrauchen sind, zB halt durch Fragmentierung. Wenn ich diese Adressen nicht mehr gebrauchen kann, kann ich auch keine Allokationen dort durchführen. Ich kann also sehrwohl 2TB unnutzbar gewordenen Adressraum haben und dabei nur 10MB an RAM wirklich verbrauchen.

Die ersten beiden Sätze versteh ich ja noch, aber der letzte Satz scheint mir reichlich widersprüchlich. Wenn ich "unnutbar gewordenen Adressraum habe", ohne in der Gesamtheit die gleiche Menge an Adressraum zu haben, dann kann ich das nicht nachvollziehen.

Und zu 32Bit: das zähle ich mal als PP. Ich jedenfalls weigere mich in meiner Freizeit über die Probleme der x86_32 Welt nachzudenken.

Dann entwickelst du halt nur für einen Teil aller Endanwender. Der Großteil meines Bekanntenkreises nutzt ein 32 Bit System und ich glaube, dass es noch weitaus mehr gibt. Was du tust ist deine Sache, aber man sollte nicht davon ausgehen, dass jeder Mensch ein 64 Bit System nutzt.

[Artificial Mind]

Das mit dem unnutzbar geworden ist im Grunde ganz einfach:
Minimalbeispiel: Stell dir vor, du hast in 1MB Schritten jeweils einen int (4Bytes) allokiert. Dein virtueller Adressraum sieht dann so aus:
int
1MB - 4bytes frei
int
1MB - 4bytes frei
...
Angenommen, du hast auf diese Art und Weise 2000 int's allokiert. Das sind dann 8KB ints die du allokiert hast (und wenn man mal pages ignoriert, wären das 8KB Ram verbrauch). Wenn du allerdings nur 32bit adressraum hast und nun 1MB (zusammenhängend) allokierten willst, dann sind ja alle dieser [int + 1MB-4bytes] Bereiche "unbenutzbar", da dort kein 1MB am Stück reinpasst. Die nächste freie Adresse wäre dann bei > 1MB * 2000 = 2GB, also außerhalb des normalerweise von 32bit allokierbaren Bereiches.

[Lynxeye]

Die ersten beiden Sätze versteh ich ja noch, aber der letzte Satz scheint mir reichlich widersprüchlich. Wenn ich "unnutbar gewordenen Adressraum habe", ohne in der Gesamtheit die gleiche Menge an Adressraum zu haben, dann kann ich das nicht nachvollziehen.

Wie gesagt Adressraum ist nicht gleich physikalisch vorhandener Speicher. Jeder Prozess in einem 64Bit Windows hat einen 8TB großen Adressraum, unabhängig davon, ob nun 512MB oder 4TB RAM im Rechner installiert sind.

Wie Adressraum durch Fragmentierung unbrauchbar wird: stell dir vor, du hast im Abstand von je 10MB im Adressraum je eine Allokation von 4KB stehen (schönes Beispiel, da genau PAGE_SIZE). Die Löcher zwischen den Allokationen sind durch vorhergehende Allokationen entstanden, welche inzwischen wieder freigegeben sind. Wenn ich nun 1000 solcher 4KB Blöcke habe, habe ich gerade mal 4MB an RAM verbraucht. Will ich nun aber eine Allokation von 11MB durchführen gelingt mir dies nicht in den ersten 10GB des Adressraumes, da dort kein zusammenhängendes Loch von 11MB Größe ist, da nach jeweils 10MB eine Allokation folgt.
Die ersten 10GB Adressraum sind also für meine 11MB Allokation unbrauchbar, obwohl ich real nur 4MB RAM verbraucht habe.

Und genau darum geht es hier: ein Speichermanager kann nur Fragmentation verhindern, nicht den physischen Speicherverbrauch. Deshalb ist es sinnlos bei 8TB Adressraum sich Gedanken darüber zu machen, ob man selber einen Speichermanager schreiben sollte, was man ohne viel Wissen und investierte Zeit sowieso nicht sinnvoller als das OS hinbekommt. Der Grundsatz von sparsamer Verwendung von Speicher gilt natürlich weiterhin ungebrochen.

[IlikeMyLife]

Wie gesagt Adressraum ist nicht gleich physikalisch vorhandener Speicher. Jeder Prozess in einem 64Bit Windows hat einen 8TB großen Adressraum, unabhängig davon, ob nun 512MB oder 4TB RAM im Rechner installiert sind.

Wenn der besagte Adressraum kein Physikalischer Speicher ist... dann muss er ja Virtuell in Form einer Art Verwaltete Auslagerungsdatei sein.

Ich gehe grade davon aus, dass es sich nicht um die eigentliche Auslagerungsdatei von Windows handelt, auch wenn ich oben im Satz diesen Ausdruck verwendet habe.

[Lynxeye]

Wenn der besagte Adressraum kein Physikalischer Speicher ist... dann muss er ja Virtuell in Form einer Art Verwaltete Auslagerungsdatei sein.

Ich gehe grade davon aus, dass es sich nicht um die eigentliche Auslagerungsdatei von Windows handelt, auch wenn ich oben im Satz diesen Ausdruck verwendet habe.

Er wird verwaltet, mit Strukturen, welche im RAM gehalten werden. Da der verwaltete Speicher virtuell ist, muss kein Teil davon physisch als RAM oder anderer Hintergrundspeicher vorhanden sein; wäre auch nicht möglich bei 8TB pro Prozess und mehreren Dutzend Prozessen pro System. Die 8TB gelten übrigens nur für Windows x64, Linux x64 stellt jedem Prozess 128TB Adressraum bereit.

Was Windows als Auslagerungsdatei bezeichnet, heißt bei der virtuellen Speicherverwaltung Swapping. Als Einführung in das Thema ist mal wieder ein Wikipediaartikel zu empfehlen, auch wenn dieser das Thema nur anreißt.

[NytroX]

Jeder Prozess hat zudem den kompletten Speicherbereich zur Verfügung, also von 0 bis 8TB (oder wieviel auch immer, je nach OS).
Man kann sich das so vorstellen, dass es quasi einen Hash gibt, der jede virtuelle Adresse in eine physikalische umwandelt, je nachdem von welchem Prozess die Anfrage kam.
Und damit das auch schön schnell vonstatten geht macht das eine eigene Funktionseinheit auf dem Prozessor, die Memory Management Unit (MMU).

Wie Adressraum durch Fragmentierung unbrauchbar wird: stell dir vor, du hast im Abstand von je 10MB im Adressraum je eine Allokation von 4KB stehen (schönes Beispiel, da genau PAGE_SIZE). Die Löcher zwischen den Allokationen sind durch vorhergehende Allokationen entstanden, welche inzwischen wieder freigegeben sind.

Und genau das kann (sollte) dank Low-Fragmentation-Heap und virtuellen Adressen nicht passieren.

Btw:
Wenn neuer Speicher allokiert wird, werden die Zwischenräume genutzt, d.h. für diese Situation müsste man erst alles Allokieren (die kompletten 10 GB) und dann alles freigeben und zwischendrin die 4 KB-Blöcke stehen lassen.
D.h. dein Programm müsste dann echt 10 GB RAM benötigen/voraussetzen.
Und selbst wenn das der Fall sein sollte hat man ja noch die anderen 7,99 TB übrig :D

Von daher einfach locker bleiben und das "Problem" mit dem Speicher erst angehen, wenn es tatsächlich nachweislich existiert. 8-)