4.3. Grundlegende Konzepte virtuellen Speichers
Obwohl die Technologie, die sich heutzutage hinter den verschiedensten modernen Speichertechnologien verbirgt, schlichtweg eindrucksvoll ist, muss der durchschnittliche Systemadministrator sich nicht n�her mit den Details befassen. Tats�chlich gibt es nur eine Tatsache, die Systemadministratoren in Bezug auf Speicher immer im Ged�chtnis behalten sollten:
Es gibt niemals genug RAM.
W�hrend diese Binsenweisheit zun�chst sehr humorvoll erscheinen mag, so haben zahlreiche Designer von Betriebssystemen geraume Zeit damit verbracht, die Auswirkungen dieses sehr realen Engpasses zu verringern. Dies wurde bewerkstelligt durch die Implementierung virtuellen Speichers — eine Art Kombination von RAM mit langsamerem Speicher, um dem System den Anschein zu geben, mehr RAM zu besitzen, als eigentlich installiert worden ist.
4.3.1. Virtueller Speicher in einfachen Worten
Beginnen wir mit einer hypothetischen Applikation. Der Maschinencode, aus dem diese Applikation besteht, besitzt eine Gr��e von 10000 Bytes. Au�erdem werden weitere 5000 Bytes zur Datenspeicherung und f�r I/O-Puffer ben�tigt. Dies bedeutet, dass diese Applikation 15000 Bytes RAM ben�tigt; sogar bei einem einzigen Byte weniger k�nnte die Applikation nicht ablaufen.
Diese Voraussetzung von 15000 Byte ist auch als Adressbereich der Applikation bekannt. Es stellt die Anzahl von einzigartigen Adressen dar, die dazu ben�tigt werden, die Applikation und deren Daten zu enthalten. In den ersten Computern musste der Adressbereich gr��er sein, als der Adressbereich der gr��ten Applikation, die darauf ablaufen sollte; ansonsten w�rde die Applikation fehlschlagen und eine "Out of Memory"-Fehlermeldung ("Speicher unzureichend") erzeugen.
Eine sp�tere Vorgehensweise, als Overlaying bekannt, versuchte das Problem zu verringern, indem Programmierer festlegen konnten, welche Teile derer Applikationen im Speicher zu jedem gegebenen Zeitpunkt resident bleiben. Auf diese Art konnte Code, der nur einmalig zu Initialisierungszwecken ben�tigt wird, mit Code �berschrieben (overlayed) werden, der zu einem sp�teren Zeitpunkt ben�tigt wird. W�hrend Overlays im Falle von Speicherknappheit Erleichterung schaffen konnten, so war dies jedoch ein sehr komplexer und fehleranf�lliger Prozess. Overlays haben auch nicht das Problem einer systemweiten Speicherknappheit w�hrend der Laufzeit angesprochen. In anderen Worten erfordert ein Programm mit Overlays zwar weniger Speicher zum Ablaufen, besitzt das System jedoch nicht gen�gend Speicher f�r das dar�bergelegte (overlayed) Programm, bleibt das Endresultat unver�ndert — eine "Out of Memory"-Fehlermeldung.
Virtueller Speicher stellt das Konzept eines Adressbereichs f�r Applikationen auf den Kopf. Anstatt sich darauf zu konzentrieren, wieviel Speicher eine Applikation zum Ablaufen ben�tigt, versucht ein Betriebssystem mit virtuellem Speicher st�ndig die Antwort auf eine Frage zu finden, n�mlich "wiewenig Speicher ben�tigt eine Applikation zum Ablaufen?"
Wobei es zun�chst danach aussieht, als ob unsere hypothetische Applikation die gesamten 15000 Bytes zum Ablaufen ben�tigt, bitten wir Sie, sich an unsere Diskussion zur�ckzuerinnern in Abschnitt 4.1 — Speicherzugriff neigt dazu, sequentiell und ortsgebunden zu sein. Daher ist die Menge an ben�tigtem Speicher (um die Applikation auszuf�hren) zu jedem Zeitpunkt weniger als 15000 Bytes — normalerweise sogar um Einiges weniger. Betrachten Sie die Arten von Speicherzugriffen, die notwendig sind, um einen einzigen Maschinenbefehl auszuf�hren:
Der Befehl wird vom Speicher gelesen.
Die Daten, die vom Befehl ben�tigt werden, werden vom Speicher gelesen.
Nachdem der Befehl durchgef�hrt worden ist, werden die Resultate des Befehls wieder zur�ck in den Speicher geschrieben.
Die eigentliche Menge von Bytes, die f�r jeden Speicherzugriff notwendig sind, variiert in Hinsicht auf CPU-Architektur, den tats�chlichen Befehl und den Datentyp. Selbst wenn ein Befehl 100 Bytes f�r jede Art von Speicherzugang ben�tigt, so sind die ben�tigten 300 Bytes immer noch viel niedriger als der gesamte 15000-Byte Adressbereich der Applikation. Wenn es eine M�glichkeit g�be, die Speicheranforderungen einer Applikation nachzuverfolgen w�hrend diese abl�uft, so w�re es m�glich die Applikation auch mit weniger Speicher, als vom Adressbereich gefordert, ablaufen zu lassen.
Da bleibt nur noch eine Frage �brig:
Wenn nur ein Teil der Applikation sich zu einem bestimmten Zeitpunkt im Speicher befindet, wo befindet sich der Rest?
4.3.2. Zusatzspeicher — zentraler Grundsatz des virtuellen Speichers
Kurz gesagt verbleibt der Rest der Applikation auf der Festplatte. In anderen Worten fungiert die Festplatte als Zusatzspeicher f�r RAM; ein langsameres, gr��eres Speichermedium dient als "Backup" f�r ein viel schnelleres, kleineres Speichermedium. Dies mag zun�chst den Eindruck eines gro�en Performance-Problems in spe erwecken — sind doch Festplattenlaufwerke um so vieles langsamer als RAM.
W�hrend dies der Wahrheit entspricht, ist es jedoch m�glich seine Vorteile aus dem sequentiellen und ortsgebundenen Zugriffsverhalten von Applikationen zu ziehen und die meisten negativen Auswirkungen auf die Leistung zu elimieren, sobald Festplattenlaufwerke als Zusatzspeicher f�r den Hauptspeicher verwendet werden. Das Subsystem des virtuellen Speichers wird dahingehend strukturiert, dass dieses versucht sicherzustellen, dass diejenigen Teile der Applikation, die sich gerade in Gebrauch befinden oder h�chstwahrscheinlich in naher Zukunft ben�tigt werden, f�r den ben�tigten Zeitraum lediglich in RAM aufbewahrt werden.
In vieler Hinsicht ist dies �hnlich der Beziehung zwischen Cache und RAM: indem ein kleiner, schneller Speicher gemeinsam mit einem gro�en, langsamen Speicher sich wie eine gro�e Menge schneller Speicher verhalten.
In Anbetracht dessen, sehen wir uns den Prozess nun einmal genauer an.
