4.4. Virtueller Speicher: Die Details
Zun�chst m�ssen wir ein neues Konzept vorstellen: virtueller Adressbereich. Virtueller Adressbereich ist die maximale Menge an Adressbereich, der einer Applikation zur Verf�gung steht. Der virtuelle Adressbereich variiert entsprechend der Systemarchitektur und ist abh�ngig vom Betriebssystem. Virtueller Adressbereich h�ngt von der Architektur ab, da die Architektur genau bestimmt wieviele Bits zu diesem Zweck zur Verf�gung stehen. Virtueller Speicherraum h�ngt ebenso vom Betriebssystem ab, da die Art in welcher das Betriebssystem implementiert worden ist, zus�tzliche Begrenzungen zur Folge haben kann, die weitaus h�her sind als jene, die auf die Architektur zur�ckzuf�hren sind.
Das Wort "virtuell" in virtuellem Adressbereich steht f�r die gesamte Anzahl von einzigartig ansprechbaren Speicherpl�tzen, die einer Applikation zur Verf�gung stehen, aber nicht f�r die Menge an physikalischem Speicher, der entweder im System installiert ist oder der Applikation zum jeweils gegebenen Zeitpunkt verschrieben ist.
Im Falle unserer Beispielapplikation besitzt der virtueller Adressbereich 15000 Bytes.
Um virtuellen Speicher implementieren zu k�nnen, muss das Computersystem spezielle Speicher-Management-Hardware besitzen. Diese Hardware ist auch oft als MMU (Memory Management Unit) bekannt. Sobald die CPU auf RAM zugreift, �ndern sich ohne MMU die tats�chlichen Hauptspeicherpl�tze nicht — z.B. Speicheradresse 123 ist immer der selbe physikalische Speicherplatz innerhalb des Hauptspeichers (RAM).
Mit MMU durchlaufen die Speicheradressen jedoch einen Umrechnungsschritt vor jedem einzelnen Speicherzugriff. Dies bedeutet, dass Speicheradresse 123 das eine Mal zur physikalischen Adresse 82043 geleitet wird und ein anderes Mal widerum zur physikalischen Adresse 20468. Wie sich herausgestellt hat, w�re der Overhead beim individuellen Verfolgen der Umrechnungen f�r Billionen von Bytes viel zu hoch. Daher unterteilt MMU den Hauptspeicher in Pages oder auch sogennate Seiten —
Diesen Pages und deren Adress-Umrechnungen im Auge zu behalten, mag wie ein unn�tiger und verwirrender Schritt klingen. Tats�chlich ist dies jedoch entscheidend bei der Implementierung virtuellen Speichers. Beachten Sie bitte dabei folgenden Punkt:
Nehmen wir unsere hypothetische Applikation mit 15000 Byte virtuellem Adressbereich und nehmen an, dass die erste Anweisung der Applikation auf Daten zugreift, die unter der Adresse 12374 gespeichert sind. Jedoch gehen wir ebenso davon aus, dass unser Computer lediglich 12288 Bytes an physikalischem Hauptspeicher besitzt. Was passiert nun, wenn die CPU versucht auf die Adresse 12374 zuzugreifen?
Was hier passiert wird als Page Fault oder Seitenfehler bezeichnet.
4.4.1. Seitenfehler (Page Faults)
Ein Seitenfehler oder Page Fault tritt dann auf, wenn ein Programm versucht auf Daten zuzugreifen (oder auch auf Code), welche sich zwar in deren Addressbereich, aber sich zu diesem Zeitpunkt nicht im RAM des Systems befinden. Das Betriebssystem muss Seitenfehler derart behandeln, dass irgendwie das Einlagern der Seite veranlasst wird und der Prozess nach erfolgtem Einlagern mit dem unterbrochenen Befehl fortgesetzt wird - genauso als ob der Seitenfehler niemals aufgetreten w�re.
Im Falle unserer hypothetischen Applikation legt die CPU zuerst der MMU die gew�nschte Adresse (12374) vor. Jedoch besitzt die MMU keine Umwandlung f�r diese Adresse. Daher unterbricht diese die CPU, wobei die als "Page Fault Handler" bekannte Software ausgef�hrt wird. Der Page Fault Handler legt sodann genau fest, was zu tun ist, um diesen Seitenfehler zu beheben. Diese Software kann:
Herausfinden, wo sich die gew�nschte Seite auf der Festplatte befindet und diese einlesen (dies ist normalerweise der Fall, wenn es sich dabei um einen Page Fault in Bezug auf Code handelt)
Ermitteln, dass die gew�nschte Seite sich bereits im Hauptspeicher befindet (aber noch nicht dem gegenw�rtigen Prozess zugewiesen ist) und die MMU rekonfigurieren, um darauf hinzuzeigen
Hinzeigen auf eine spezielle Seite, die lediglich Nullen enth�lt und sp�ter dem Prozess eine neue Seite zuweisen. Dies geschieht jedoch nur unter der Voraussetzung, dass der Prozess jemals auf diese Seite schreibt (dies wird als sogenannte Copy on Write-Seite bezeichnet und wird oft f�r Seiten verwendet, die Null-initialisierte Daten enthalten).
Holt Sie die gew�nschte Seite von irgendwo anders (was sp�ter noch genauer behandelt wird)
Im Gegensatz zu den ersten drei Abl�ufen, die relativ unkompliziert sind, ist die Letzte nicht ganz so einfach. Dazu m�ssen wir einige zus�tzliche Themenbereiche abdecken.
4.4.2. Die Arbeitsmenge (Working Set)
Die Menge der physikalischen Seiten, die gegenw�rtig einem bestimmten Prozess gewidmet sind, werden f�r diesen Prozess als Working Set oder Arbeitsmenge bezeichnet. Die Working-Set-Gr��e (Anzahl der Seiten) kann dabei wachsen und schrumpfen, abh�ngig von der allgemeinen Verf�gbarkeit von Seiten auf einer systemweiten Basis.
Der Working Set erweitert sich, sobald ein Prozess einen Seitenfehler hervorruft. Der Working Set schrumpft, sobald immer weniger freie Seiten vorhanden sind. Um das v�llige Auslaufen von Speicher zu vermeiden, m�ssen Seiten aus der Arbeitsmenge ausgelagert werden und in freie Seiten zur sp�teren Benutzung umgewandelt werden. Das Betriebssystem schrumpft Arbeitsmengen (Working Sets) von Prozessen wie folgt:
Modifizierte Seiten werden in einen eigens daf�r bestimmten Bereich auf einem Massenspeicherger�t geschreiben (welcher normalerweise als Swapping- oder Paging-Space bekannt ist)
Unmodifizierte Seiten werden als frei gekennzeichnet (es besteht kein Anlass, diese unver�nderten Seiten nochmals auf eine Festplatte zu schreiben)
Um geeignete Working Sets f�r alle Prozesse festzulegen, muss das Betriebssystem Nutzungs-Informationen f�r alle Seiten ausfindig machen. Auf diese Art legt das Betriebssystem fest, welche Seiten aktiv genutzt werden (und speicher-resident bleiben) und welche Seiten nicht genutzt werden (und daher vom Speicher verdr�ngt werden k�nnen). In den meisten F�llen bestimmt eine Art von 'am-wenigsten-j�ngst-bentutzt' Algorithmus (LRU oder auch "least recently used"), welche Seiten verdr�ngt werden k�nnen (da wahrscheinlich nicht mehr in einer Lokalit�t).
4.4.3. Seitenaustausch (Swapping)
Obwohl Swapping (das Auslagern modifizierter Seiten in den Swap-Space des Systems) ein ganz normaler Systemvorgang ist, kann auch ein �berma� an Swapping auftreten. Warum man sich vor exzessivem Swapping h�ten sollte, wird dadurch ersichtlich, dass folgende Situation immer wiederkehrend auftreten kann:
Seiten eines Prozesses werden ausgetauscht
Der Prozess versucht auf eine ausgetauschte Seite zuzugreifen
Die Seite wird wieder in den Speicher eingelagert (wobei h�chstwahrscheinlich die Seiten anderer Prozesse verdr�ngt werden)
Kurze Zeit sp�ter wird die Seite wieder ausgelagert
Wenn die Gesamtheit der Lokalit�ten aller Prozesse den Arbeitsspeicher sprengt, droht Thrashing oder auch Seitenflattern genannt. Dies ist ein Indikator f�r ungen�genden Arbeitsspeicher f�r die gegenw�rtige Arbeitslast. Thrashing hat h�chst nachteilige Auswirkungen auf das Leistungsverhalten des gesamten Systems, da eine extrem hohe CPU- und I/O-Arbeitslast durch das hektische Ein-/Auslagern generiert wird. In extremen F�llen kann es dazu kommen, dass das System tats�chlich keine n�tzliche Arbeit mehr leistet, da es zu besch�ftigt mit dem Auslagern und Einlagern von Seiten ist.
