Hauptspeicher - Universität Ulm

4. Hauptspeicher 

4.1 Einführung 

4.1.1 Anforderungen an die Speicherverwaltung 

• Partitionierung und Strukturierung des Hauptspeichers: 

- Traditionell eine Partition pro Programm, 

- Halde, Keller, Code, Systembereiche, Puffer .... 

- statische und dynamische Unterteilung, 

• Speicherzuteilung: 

- New(), Malloc(), Prozeduraufruf, Load ... 

• Freispeichersammlung: 

- Copy Collectoren, Mark & Sweep ... 

• Auslagern von Programm(teil)en: 

- Overlay Techniken, Swapping, virtueller Speicher. 

1 Betriebssysteme Sommer 2004, ©VS Informatik, Universität Ulm, P. Schulthess

4.1.2 Speicherhierarchie 

• Cache: 

- Teuer, flüchtiger Inhalt, Kapazitäten in Kilobyte, meist mehrstufig, 

- Beispiel Athlon XP: 128 kB L1 Cache, 256 kB L2 Cache (auf Chip). 

- On-Chip mit vollem CPU-Takt, Off-Chip mit halbem CPU-Takt. 

• Hauptspeicher: 

- flüchtiger Inhalt, schneller Zugriff (z.B. SDRAM 5 ns). 

- DDR 800 RAM theoretisch bis zu 3,2 GB/s. 

- Kapazität in Megabyte (z.B. 512 MB). 

• Plattenspeicher: 

- Kostengünstige persistente Speicherung. 

- Zugriffszeiten in Millisekunden (z.B. 7ms). 

- IDE Festplatten erreichen bis zu 50 MB/s. 

- Kapazität in Gigabyte (z.B. 200 GB). 

• Die Speicherverwaltung organisiert den Transfer 

zwischen den Ebenen. 

CPU 

Host- 

Brücke 

E/A- 

Brücke 

L1 Cache 

Daten Code 

L2 Cache 

Hauptspeicher 

Festplatten 


4.1.3 Begriffe 

• Speicherblock: Menge von fortlaufenden logischen Speicheradressen. 

• Partition = (größerer) Gesamtspeicherblock für ein Programm. 

• Swapping = Aus- und Wiedereinlagern von ganzer Partitionen auf Disk. 

• Physikalische (absolute) Speicheradresse: bezeichnet/zeigt in physisch 

vorhandenen Hauptspeicher. 

• Logische Speicheradresse: Position im HS aus Sicht des Programmes, unabhängig 

von der physikalischen Speicherorganisation. 

• Relative Speicheradresse: Position relativ zu einem bekannten Punkt im 

Programm. 

- im Prinzip eine spezielle logische Adresse, 

- meist relativ zum Programmzähler, 

- oder zum Programmbeginn, 

- für Sprünge und Aufrufe. 


4.1.4 Binden von Speicheradressen 

• Compiler erzeugt Objektdateien: 

- pro Modul/Klasse eine Objektdatei. 

- innerhalb der Objektdatei relative Adressierung. 

- übergreifende Aufrufe über Importtabelle realisiert. 

• Linker/Binder: 

- Löst Referenzen auf importierte Funktionen/Variablen/Klassen auf. 

- Bindet Objektdateien zu einem ausführbaren Programm. 

- Prüft die Konsistenz der Schnittstellen. 

Lader: 

- bringt Programm zur Ausführung in den Hauptspeicher, 

- reloziert das Objektmodul, bzw. passt die Adressen an. 

- Anbinden von Standarddateien. 


• Adressbindung zum Übersetzungs- oder Linkagezeitpunkt: 

- fest „verdrahtete“, eingetragene Adresse im ausführbaren Programm. 

- Programm. muss an eine bestimmte Adresse geladen werden. 

� Konflikte bei Mehrprogrammbetrieb 

int main() { 

GetVersion(); 

} 

main: 

call [pc-256] 

Hauptspeicher 

kernel32.dll 

GetVersion 

0x4711 

test.exe 

0x4711 

5 Betriebssysteme Sommer 2004, ©VS Informatik, Universität Ulm, P. Schulthess 

-256

• Adressbindung zur Ladezeit: 

- Funktionstabelle mit importierten Funktionen wird vom Lader ausgefüllt. 

- Verweise auf externe Variablen werden aufgelöst 

- ESD - "External Symbol Dictionary" ... 

• Adressbindung zur Laufzeit: 

- erlaubt die Relozierung/Verschiebung des Programms zur Laufzeit, 

- Evtl. Verbindung zu shared Libraries und gemeinsamem Speicher, 

- Evtl. mithilfe der Memory Management Unit im Prozessor. 

- logische versus physikalische Adressen. 

CPU 

logische 

Adresse 

4711 

+ 

MMU 

Adressübersetzung 

10000 

phys. 

Adresse 

14711 



4.2 Anforderungen an die Hauptspeicherverwaltung 

• Ausgangssituation: Mehrprogrammbetrieb 

- mehrere Programme teilen sich den Hauptspeicher. 

- vorab ist unklar, welche Programme zu einem Zeitpunkt geladen sind. 

• Zuteilung von Speicherblöcken: 

- Schnell, und mit möglichst geringem Verschnitt. 

- Berücksichtigen von allfälligen Speicherquoten, 

• Freigabe von Speicherblöcken: 

- Aufräumen beim Terminieren eines Programmes. 

- manuelles oder automatisches Einsammeln. 

• Aus- und Einlagern von Programmen: 

- inaktive Programme und Speicherseiten auslagern. 

- somit bessere Ausnutzung des HS & CPU. 


• Relozierung: 

- Wiedereinlagern eines Programms kann an anderer Adresse erfolgen. 

- somit muss Programm relozierbar sein und alle Zeiger angepasst werden. 

- benötigt HW-Unterstützung (z.B. Segmente). 

- Relozierung auch zur Kompaktifizierung. 

• Gemeinsame Nutzung von Hauptspeicher: 

- Kooperation auf gemeinsamen Daten (Shared Memory). 

- vermeiden von Code-Redundanz, 

- mit Zugriffskontrolle, 

• Speicherschutz: 

- Betriebssystem in der Regel geschützt. 

- Schutz gegen ungewollte/absichtliche Störungen durch andere Progr. 

- Zugriff auf Speicher fremder Prg. nur mit besonderer Genehmigung. 

- Unterstützung durch Hardware (z. B. Segmente). 

- typsichere Sprachen von Vorteil (z.B. Java). 


• Logische Organisation : 

- Der Hauptspeicher ist als linearer Adressraum aufgebaut. 

- Programme sind üblicherweise modular realisiert. 

- Segmente bieten passende logische Struktur: 

- gemeinsame Nutzung gewisser Bereiche 

- verschiedene Schutzkategorien. 

Physikalische Organisation: 

- Speicher des Rechners in typischerweise in 3 Ebenen unterteilt (Cache, Hauptspeicher und 

Festplatte), 

- Informationsfluss zwischen diesen beiden Ebenen ist Aufgabe der Speicherverwaltung und 

der Hardware, 

- Anwendungsprogramme erhalten eine konsistente Speichersicht. 

• Virtueller Speicher: 

- Eventuell Abbildung logischer Adressen auf physikalische, 

- Verschiedene Overlaytechniken, 

- Segmentierung oder Paging. 


4.3 Partitionen im Hauptspeicher 

Multiprogramming : 

- Ziel: Überlappen von E/A-Operationen und Verarbeitung, 

- Mehrere Programme werden gleichzeitig in versch. Partitionen gehalten, 

- Je nach BS können Partitionen auch geswappt werden (Auslagern), 

- Die Programme müssen voreinander geschützt werden, 

- Ältere Betriebssysteme kannten noch keinen virtuellen Speicher, sondern verwendeten eine 

Aufteilung des Hauptspeichers in Partitionen. 

4.3.1 Statische Partitionierung 

• Statische Unterteilung des Hauptspeichers in gleich große oder variabel große 

Partitionen. Jedes Programm erhält eine eigene Partition. 

• Während der Laufzeit kann diese Zuordnung nicht mehr verändert werden. 

• Es wird die kleinste Partition zugewiesen in die das Programm hineinpasst. 

• Sind alle Partitionen belegt, so warten Prg. in einer Zuteilungsschlange. 


Partitionen fester Größe (z.B. 8 

MB) mit mehreren Warteschlangen: 

Warteschlangen 


Partition 4 

Partition 3 

Partition 2 

Partition 1 

Betriebssystem 

Warteschlange 

(wartende Prgs.) 

• einfach implementierbar. 

• maximale Anzahl Programme festgelegt. 

• Der Speicherbedarf muss vorab bekannt sein. 

• Ungenutzter Platz in einer Partition ist verloren 

� interne Fragmentierung/Speicherverschnitt 

Variable Partitionen und eine 

Warteschlange: 


Partition n 

Partition 2 

Partition 1 



4.3.2 Dynamische Partitionierung 

• Länge, Anzahl und Anfangsadresse einer Partitionen ändern sich dynamisch. 

• Programm erhält genau so viel Speicher wie es benötigt und nicht mehr. 

• Interne Fragmentierung innerhalb einer Partition wird verhindert. 

• Aber ein neues Problem entsteht: externe Fragmentierung: 

- im Laufe der Zeit entstehen Löcher zwischen den Partitionen. 

- ein neues Programm kann eventuell nicht geladen werden, 

- aber Programm passt in keine Lücke, obschon insgesamt genügend Speicher vorhanden ist, 

Lösung: Heap Kompaktierung 

- Im Prinzip möglich, wenn die Partitionen relozierbar sind, 

- evtl. HW Unterstützung (Segmentdeskr., Basisregister, Virtueller Sp.) 

- unter Umständen viele Partitionen umkopieren und Adressen neu binden. 


• Beispiel für externe Fragmentierung: 

- Programm P4 kann erst geladen werden, nachdem P2 und P3 verschoben wurden. 

n 

0 



freier 

Speicher 

P1 

P2 

P3 

kompaktieren 




P4 

P1 

P2 

P3 

P4

4.3.3 Struktur einer Partition 

• Heap (Halde): 

- Explizite Allozierung zur Laufzeit, 

- für dynamische Datenstrukturen, 

- Ressourcen (Code, Puffer, ..). 

• Stack (Keller): 

- Parameter & lokale Variablen, 

- Rückkehradressen, Nesting ... 

- Hinweis: schwer identifizierbare Fehler, 

falls Stack und Heap sich 

überschneiden. 

• Globale Variablen: 

- Modulübergreifende Daten, 

• Code-Abschnitt: 

- eine oder mehrere Methoden, 

- meist schreibgeschützt, 

- ... 

high 

memory 

low 

frei 

globale Variablen 

Code 

Keller 

ESP 

Halde 


4.3.4 Format von Heapblöcken: 

• Ein Aufruf von new() ode malloc() liefert einen neuen Heapblock. 

• Header: 

- enthält Informationen für Speicherverwaltung und Freispeichersammlung: 

- Längenfelder, nächster Heapblock, Containergrösse, Anzahl Elemente, 

- Header normalerweise außerhalb des Nutzer-Blocks, 

- Flags: Locked, Read-Only, Free, Marked … 

- Typ: zB. Zeiger auf den Klassendeskriptor, 

• Auch ein nicht belegter Block braucht typischerweise einen Header. 

Heapblock 

Header Nutzerdaten und -code 

Heapblock 

Header leer 

Heapblock 

Header Nutzerdaten und -code 


4.3.5 Doppelköpfige Heapblöcke in Plurix 

• doppelköpfiges Format: 

- Trennung von Zeigern und Skalaren, 

- vereinfacht das Heap-Management. 

- Header in der Mitte des Blocks, 

- Zeiger zeigen auf den Header, 

- Zwei Längenfelder. 

• Rückwärtsverkettung: 

- Vereinfacht Garbage Collection, 

- Garbage hat leere Backchain, 

- BC vereinfacht Relozierung, 

- zirka 3 Backlinks in-line, 

- weitere Backlinks extern. 

• Stopper synchronisiert 

Heapwalk. 

• Winglets erlauben das Durchlaufen des 

Heaps in beiden Richtungen. 

Backlinks 

Zeiger 

Winglet 

Header 

Flags 

Winglet 

Skalare 


4.3.6 Handles & Masterzeiger: 

• Nur der Masterzeiger referenziert 

die Daten. 

• Ein Handle als Zeiger auf einen 

MasterZeiger. 

• Eventuell verweisen viele 

Handles auf einen MasterZeiger: 

• Verwendet in 16 Bit Windows 

3.x und älteren MacOS 

Versionen. 

aHandle 

bHandle 

cHandle 

MasterPtr 

• Vorteil: Der Speicherblock ist relozierbar, auch wenn nicht alle 

Referenzen/Handles bekannt sind und angepasst werden könnten, 

• Beim Dereferenzieren von Handles ist Vorsicht geboten, damit die 

Speicherverwaltung nicht unbeobachtet Verschiebungen vornimmt. 

relozierbarer Block 


4.4.1 Kellerrahmen („Stackframe“) 

4.4 Laufzeitkeller bzw. Stack 

• Welche Informationen werden für einen Prozeduraufruf im Keller 

festgehalten? 

• Aufgaben des Kellers: 

- Variablen im Keller, kein Code, 

- Funktionsresultat nur bei Funktionen. 

- Übergabe von Prozedurparametern, 

- Rücksprungadresse nach Abschluss, 

- Funktionsprinzip: „Last in First Out“. 

- Speichern von lokalen Variablen, 

- "Save area" für CPU-Register. 

• Zwischenresultate von Berechnungen. 

• Eventuell Parameter in Registern. 

Base 

pointer 

stack front 

Funktionsresultat 

Parameter 

Parameter 

Rücksprungadresse 

statische 

statische 

Verkettung 

Verkettung 

dynamische Verkettung 


dynamische lokale Variablen 

Registeraufbewahrung 

Verkettung 

lokale Variablen 

temporäre 

Zwischenwerte 

stack front 

Registeraufbewahrung 

temporäre Zwischenwerte 


stack frame

4.4.2 Dynamische & statische Verkettung: 

• Dynamisch: 

- Bei Rücksprung aus einer Prozedur muss der alte Kellerrahmen wieder gefunden werden. 

• Statische Verkettung: 

- bei Sprachen, die geschachtelte Prozeduren erlauben. 

- innere Prozeduren haben Zugriff auf lokale Variablen von Äußeren. 

- diese Var. müssen im Stack adressierbar sein. 

Programm 

Proc B 

Proc C 

Proc A 

Globale Var. 

stack front 


Static chain 

A 

A 

B 

C 

C 

B 

C 

B 

dynamic chain

4.4.3 Displaytabelle 

• Alternative Implementierung zur statischen Verkettung. 

• Spiegelt verschachtelte Gültigkeitsbereiche des Quellprogramms wieder: 

- Compiler kennt aktuelle lexikalische Ebene, jedoch nicht Rekursionstiefe. 

- Displaytabelle liegt an definierter Speicherposition. 

- Globale Variablen auf lexikalischer Ebene #0. 

20 

Programm 

Globale 

LL #0 

Proc B 

Proc C 

Variablen 

A-Variablen 

B-Variablen 

LL #1 

LL #2 

LL #3 

Proc B 

C-Variablen 

Keller 

LL #4 

Displaytabelle 

Betriebssysteme Sommer 2004, ©VS Informatik, Universität Ulm, P. Schulthess

4.4.4 Kellerrahmen bei Intel x86 

• Keller wächst nach unten: 

- Ein Eintrag belegt 32-Bit. 

- 16-Bit mögl., aber nicht empfohlen. 

• EBP = Extended Base Pointer: 

- 32 Bit Register, 

- zeigt auf den akt. Kellerrahmen. 

• ESP = Extended Stack Pointer: 

- 32 Bit Register, 

- zeigt auf nächsten freien Stack-Eintrag. 

EBP 

ESP 

• Adressierung: 

- Parameter mit pos. Index relativ zu EBP. 

- lokale Variablen mit neg. Index relativ zu EBP. 

Parameter 


altes EBP 

lokale Variablen 

unbelegt 


4.4.5 Aufrufkonventionen 

• Die Aufrufkonvention ist abhängig von der Programmiersprache. 

• Programmiersprache C zum Beispiel: 

- Param. werden von rechts nach links übergeben. 

- Die aufrufende Prozedur räumt den Keller auf. 

- Funktionsresultate werden in Registern zurückgegeben. 

int add(int x, int y) 

{ 

int result; 

} 

... 

result = x + y; 

return result; 

add(5, 7) 

push EBP 

mov EBP,ESP 

sub ESP,4 

mov EAX,[EBP+8] 

add EAX,[EBP+12] 

mov [EBP-4],EAX 

mov EAX,[EBP-4] 

mov ESP,EBP 

pop EBP 

ret 

push 7 

push 5 

call add 

add ESP 8 


• Programmiersprache Pascal, zum Beispiel: 

- Funktionsresultate werden über den Keller zurückgegeben. 

- Parameter werden von links nach rechts übergeben. 

- Die aufgerufene Prozedur räumt den Keller auf. 

function add(x,y:integer):integer 

begin 

int result; 

result := x + y; 

add := result; 

end; 

... 

add(5, 7) 

push EBP 

mov EBP,ESP 

sub ESP,4 

mov EAX,[EBP+12] 

add EAX,[EBP+8] 

mov [EBP-4],EAX 

mov EAX,[EBP-4] 

mov [EBP+16],EAX 

mov ESP,EBP 

pop EBP 

ret 8 

push 0 

push 5 

push 7 

call add 

pop eax 


• Optimierung bei RISC-Prozessoren: 

- Eliminierung von Stackframes. 

- Parameterübergabe in Registern. 

- RISC Prozessoren haben viele Register, 

- und die Mögl., diese umzunummerieren. 

• Registerfenster ( -window): 

- Stack findet grösstenteils in den vielen Registern statt. 

- Relative Registeradressierung. 

#32=> 

#31=> 

96 Stack 

Register 

Output-Par. 

Lokale V. 

Input-Par. 

Verdeckte 

Register 

32 globale 

Register 

Call B 

#32=> 

#31=> 

Stack 

Lokale V. 

Input-Par. 

Verdeckte 

Register 

32 globale 

Register 

Return B 

#32=> 

#31=> 

Stack 

Rückgabe 

Lokale V. 

Input-Par. 

Verdeckte 

Register 

32 globale 

Register 


Aspekte einer Speicherverwaltung 

• Granularität der Speicherblöcke. 

• Belegungsdarstellung. 

4.5 Speicherverwaltung 

• Verschnitt (intern & externe Fragmentierung). 

• Auswahlstrategie (für freie Stücken). 

• Wiedereingliederung. 

4.5.1 Wiedereingliederung 

• Bei Freigabe eines Speicherblocks 

prüfen, ob Nachblöcke frei sind und 

gegebenenfalls zusammenfassen. 

• Hiermit entstehen wieder größere 

Blöcke. 

belegt frei belegt frei belegt 

belegt 

Freigabe 

frei belegt 


4.5.2 Belegungsdarstellungen 

Bitvektor: 

• Speicher wird in Einheiten fester Länge (z.B. 512 Byte oder 4 KB) unterteilt. 

• Jeder Einheit wird ein Bit in einem Bitvektor (Bitmap) zugeordnet. 

• Je kleiner die gewählte Einheit, desto größer ist der resultierende Bitvektor. 

• Je größer die Einheit, desto mehr interne Fragmentierung tritt auf. 

• Beispiel: 128 MB HS in 512 Byte Blöcke unterteilt, ergibt 32 KB Bitvektor. 

• Belegung eines Speicherbereichs erfordert das Durchsuchen des Bitvektors 

nach Nullbit-Folgen (sehr aufwendig). 

• Beispiel: 

0 

Prg. A Prg. B 

Prg. C 

Bitvektor/Bitmap 

0111110000111111110000001111111111110000 26 Betriebssysteme Sommer 2004, ©VS Informatik, Universität Ulm, P. Schulthess 

x

4.5.3 Freispeichertabelle etc.: 

• Speicher muss nicht in Einheiten 

fester Länge unterteilt werden. 

• freie Speicherblöcke in Tabelle. 

• sortiert nach Adresse/Größe. 

Freispeicherliste: 

• freie Speicherblöcke mit Zeiger verketten. 

• eventuell mehrere Listen: 

- verschied. Größen separat verketten, 

- pro Programm, ... 

• Optimierung: 

- Binärbaum für Zugriff, 

- Blockgröße als Schlüssel. 

0 

Prg. 

A 

Prg. 

A 

Prg. 

B 

Adr. Länge 

0 1 

6 4 

19 6 

39 4 

Prg. 

B 

Prg. 

C 

Länge Adr. 

1 0 

4 6 

4 19 

6 39 

Prg. 

C 

0 x 


x

Linearer Heap: 

• freie & belegte Blöcke sind dicht aneinander gereiht. 

• Verkettung erfolgt über das Längenfeld. 

• optimale Ordnung der Blöcke ist schwierig. 

• interne Zeiger sind überflüssig. 

• z.B. Mac OS & Plurix. 

Prg. 

A 

Prg. 

B 

Prg. 

C 

1 5 4 8 6 12 4 

0 x 

Länge eines Blocks 


4.5.4 Buddy-System: 

• Zwei gleichgroße benachbarte Blöcke nennt man Buddys („Kumpels“). 

• Speicher besteht aus 2 kmax Einheiten. 

• Speichervergabe in Blockgrößen 2 k . 

• Jeweils Liste für Blöcke der Größe 

2 k . 

• Variante in Linux-Kern verwendet. 

• Ablauf Anforderung: 

- Aufrunden auf nächste Zweierpotenz 

- Zugriff auf erstes freies Stück der Liste 

• Falls Liste leer (rekursiv): 

- Zugriff auf Liste der nächsten Größe. 

- Stück entfernen & halbieren. 

- Hintere Hälfte (=Buddy) in zugehörige 

Liste einhängen. 

2 4 

2 5 

2 6 

2 kmax 

• Kleiner Stücke entstehen aus (fortgesetzter) Halbierung größerer Stücke. 

• Benachbarte kleinere Stücke werden bei der Freigabe wieder vereinigt. 


...

• Ablauf der Speicherfreigabe: 

- Buddy bestimmen, 

- falls Buddy frei � Vereinigung . 

- falls Buddy belegt, freigewordenes Stück in die Liste einhängen. 

- Vorgang iterieren, bis Buddy belegt oder bei der max. Größe angekommen. 

• Vorteil: schnelles Verschmelzen freiwerdender Blöcke. 

• Nachteil: sowohl interne als auch externe Fragmentierung. 

Alloc 5 MB 

Alloc 3 MB 

Alloc 12 MB 

Free 3 MB 

Free 12 MB 

Free 5 MB 

2 M 

4 M 

8 M 


12 M 

16 M 

32 M

4.5.5 Auswahlstrategie 

• Kriterien: Verschnitt und Geschwindigkeit. 

• Gute Strategie kommt mit kleinem Heap aus. 

„First Fit“: 

• durchsucht die nach Adressen sortierte Liste immer ausgehend vom Anfang. 

• nimmt ersten freien Block der groß genug ist. 

• Zu grossen Block eventuell teilen, um ungebrauchten Platz zu sparen: 

- ohne Teilen � interne Fragmentierung 

- mit Teilen � externe Fragmentierung 

Vorteil: sehr schnelle Speicherzuteilung. 

Nachteil: Konzentration belegter Stücke am Anfang. 


„Next Fit“: 

• Freispeicherliste (sortiert nach Adresse) wird zyklisch durchlaufen. 

• Suche beginnt immer an der Stelle, wo letzte Belegung stattgefunden hat. 

• Eigenschaften wie „First Fit“, vermeidet aber die Konzentration von belegten 

Blk. am Anfang. 

0 x 

Stelle der letzten Belegung 


„Best Fit“: 

• sucht den Block, der am wenigsten Speicherverschnitt verursacht. 

• Unter Umständen nach Größe sortierte Freispeicherliste. 

• evtl. Binärbaum mit Größe als Schlüssel für Zugriff, um lineare Suche zu 

vermeiden. 

• Vorteil: keine Zerschneidung großer Stücke. 

• Nachteil: langsam; neigt bei Zerschneiden dazu sehr kleine unbrauchbare 

Stücke zu erzeugen. 

„Worst Fit“: 

• nimmt größten freien Block, damit noch brauchbare Stücke übrig bleiben. 


4.6.1 Overlay Technik 

4.6 Auslagern von Speicher 

• Notwendig, wenn das Programm größer als der Hauptspeicher ist. 

• Idee: Nicht benötigte Programmteile werden andere überlagert. 

• Realisierung: ein Wurzelsegment muss immer im HS sein. 

• Overlays werden vor dem Binden durch den Programmierer festgelegt. 

• Unterstützung von Programmoverlays durch: 

- Betriebssystem (z.B. MSDOS), 

- Compiler (z.B. Turbo Pascal � Units). 

• Problem: Der HS-Bedarf für die Daten 

ist schwer abschätzbar. 

• In Systemen mit virtuellem Speicher 

ist Overlaytechnik meist überflüssig. 

34 


Overlay- 

Bereich 

Wurzelsegment 


n 

0 


4.6.2 Swapping 

• Swapping = Aus- und Wiedereinlagern auf Disk von ganzen Programmen 

oder Partitionen. 

• Notwendig im Multiprogrammbetrieb, falls nicht genügend Hauptspeicher. 

• Zeitaufwendig, da immer eine ganze Partition aus- und eingelagert wird. 

• Eventuell erfolgt später die Wiedereinlagerung an anderer Adresse. 

• Benötigt HW-Unterstützung. 

• Strategien: 

- Auslagern nicht rechenbereiter Programme 

- Prioritäten berücksichtigen. 

- Wurde in Windows 3.x eingesetzt. 

- Früher hat Unix auch Swapping eingesetzt: 

- zusätzlich zum Paging (virtueller Speicher), 

- wenn kein Proz. mehr genügend Speicher hat. 

- also nur in extremen Wettbewebsituationen. 


= Garbage Collection (GC) 

4.7 Automatische Freispeichersammlung 

• Explizite Rückgabe durch Programmierer ist fehleranfällig & mühsam: 

- Abbau komplexer Strukturen oft schwierig. 

- Destruktoren in OO Sprachen (z.B. C++) löschen u. U. weitere Objekte. 

- wird ein Objekt zu früh freigegeben => Dangling Pointers (baumelnde). 

- wird vergessen Speicher freizugeben => Memory Leaks (Speicher Leck). 

• Lösung: automatische Freispeichersammlung: 

- nicht mehr adressierbare Blöcke automatisch identifizieren und freigeben. 

- Entweder für ein einmzelnes Programm oder systemweit, 

- Beispiele: Java, .NET, Oberon, ... 

• Voraussetzungen: 

- sämtliche Referenzen auf einen Speicherblock müssen auffindbar sein. 

- typsichere Sprache dringend empfohlen. 

• Aufrufen der GC: 

- Implizit durch das OS, 

- explizit durch den Programmierer, 

- oder bei Bedarf, wenn der Speicher knapp wird. 


4.7.1 Grundprinzip der Freispeichersammlung 

Collector: sammelt Garbage. 

Mutator: alle Programme, welche den Heap ändern (mutieren). 

1. Phase: Garbage Detection 

Erkennung von referenzierbaren und nicht mehr referenzierbaren Objekten. 

2. Phase: Garbage Reclamation 

Freigabe des Speichers von nicht mehr referenzierbaren Objekten. 

• Nicht mehr referenzierbare Objekte: 

- Es existiert kein Pfad zwischen dem Objekt und einer Zustandsvariablen. 

• Zustandsvariablen (Root-Set): 

- Klassenvariablen, 

- globale Variablen, 

- lokale & Modulvariablen. 

• Zirkulärer Garbage ist unangenehm: 

- jedes Objekte noch referenziert, 

- aber nicht vom Root-Set aus erreichbar. 

- Zyklus muss erkannt & aufgebrochen werden. 


4.7.2 Compilerunterstützung 

• Referenzen innerhalb eines Blocks 

müssen identifizierbar sein. 

• Benötigt wird: 

- Offset und Typ der globalen 

X ^Y 

Zeigervariablen, A ^X 

- Offset und Typ der lokalen 

^Y 

Zeigervariablen, 

Global 

- Identifikation von Kellerrahmen, 

Stack 

- Zeigerfelder in dynamisch allozierten 

Records bzw. Instanzen. 

• Vereinfachung durch 

doppelköpfiges Layout für 

Speicherblöcke (siehe 4.3.3). 

B 

Global Frame 

Proc-A Frame 

Proc-B Frame 

Record-X Type 

Record-Y Type 

… 

X 

Y 

Y 

^Y 

^X 

^X 

^Y 

^Y 

Heap 

Tabelle 

– – – – – –^Y – – 

– –^X – – – – – – 

–^Y – – – – – – – 

– – – –^Y – – – – 

– ^X – – – –^Y – – 


4.7.3 Mark & Sweep 

• Der Sammelalgorithmus markiert alle noch erreichbaren Blöcke im Heap: 

• Ausgehend von einer Menge von Wurzel-zeigern werden alle noch aktiven 

(live) Zeiger und deren Objekte gefunden. 

• Nicht markierte Blöcke sind dann frei (bzw. Garbage) und können 

eingesammelt werden. 

• Erforderliche Symbol- und Typentabelle wird vom Compiler erzeugt. 

• Die Markierungsphase muss in einem Stück zu Ende laufen. 

� Manipulation an Zeigern durch den Mutator würden GC verwirren. 

• 

Garbage 


für jede Zustandsvariable s: 

Markiere(s); 

für jedes Objekt o, für das gilt o.mark = 0 : 

Speicherfreigabe(o) 

Markiere(s): 

wenn s.mark = 1 dann beende Prozedur 

s.mark := 1; 

für jedes von s referenzierteObjekt o: 

Markiere(o) 

Vorteil: Zyklen werden erkannt. 

- Funktion zum Markieren beinhaltet unter Umständen tiefe Rekursion 

es ist viel Speicherplatz im Keller notwendig, 

- Alternativ mit Zeigerrotation arbeiten. 

• Das Verschieben von Blöcken zur Gewinnung von größeren Bereichen 

(Kompaktieren) ist möglich aber mühsam. 


4.7.4 Inkrementelles Mark & Sweep 

• Nebenläufiges Mark & Sweep nach einer Idee von E. W. Dijkstra, 1978. 

• Objekte werden mit drei Farben markiert: 

- blau: Objekt wurde komplett untersucht. 

- rot: Objekt wurde noch nicht inspiziert. 

- grün: Objekt wurde bereits besucht, aber noch nicht alle seine Nachfolger. 

• Alle besuchten Objekte werden blau markiert und alle von hier aus 

erreichbaren Obj. grün. 

• Der Algorithmus terminiert, wenn keine grünen Objekte mehr existieren. 

• Der Collector schiebt eine Front grüner Objekte vor sich her: 

• Es werden u.U. nicht alle 

Garbage Objekte in einem 

Durchlauf eingesammelt. 

41 

Rootset 

bereits untersucht 

wird gerade 

untersucht 

noch nicht 

erreicht 


• Bedingung: bereits untersuchte Objekte, dürfen keine Zeiger auf noch nicht 

untersuchte Objekte beinhalten: 

• Erfolgt eine Zuweisung einer Referenz von einem blauen auf ein rotes Objekt, 

so muss das Letztere grün eingefärbt werden. 

� Zeigerzuweisungen überwachen 

bereits untersucht 

wird gerade 

untersucht 

muss grün 

eingefärbt werden 

noch nicht 

erreicht 

Nachteil: Überwachung von Zeigerzuweisungen zur Laufzeit ist teuer. 

• Compiler fügt z.B. für jede Zeigerzuweisung einen Aufruf an eine Laufzeitroutine 

ein. 


4.7.5 Kopierende Freispeichersammlung 

• Erste Implementierung Marvin Minsky, 1963. 

• Halde in zwei Regionen alt & neu unterteilt. 

• Alle vom Rootset aus erreichbaren Objekte werden rekursiv in die neue 

Region kopiert. 

• Garbage verbleibt in alter Region. 

• Beim nächsten GC-Aufruf tauschen 

die alte und neue Region ihre Rollen. 

• Vorteil: 

alte Region 

- Heap wird automatisch kompaktifiziert. neue Region 

- Zyklen werden eliminiert. 

Nachteile: 

- Es ist teuer, viele kleine Objekte zu kopieren. 

- logischer Adressraum wird halbiert. 

- Kopieren muss atomar erfolgen. 


4.7.6 Inkrementeller Copying Collector 

• Bei jedem Aufruf der GC wird 

nur eine vorgegebene Anzahl 

von Objekten kopiert. 

• Es muss nicht für längere Zeit 

die ganze Verarbeitung 

gestoppt werden. 

Iterative Lösung nach Cheney: 

• Neue Region wird fortlaufend 

gefüllt � Queue. 

A 

C 

alte Region 

A=Root 

B 

D A‘ 

• scan-Zeiger: Objekte bis hier sind komplett abgearbeitet. 

neue Region 

Beim Scannen von A‘ 

wird D kopiert 

D‘ 

scan free 

• free-Zeiger: Objekte zwischen scan- und free-Zeiger sind kopiert, aber haben 

noch Zeiger in die alte Region. 

• Kopierte alte Objekte verweisen auf Ihre Kopie (z.B. A = Root-Variable). 


• Der Algorithmus terminiert, wenn scan-Zeiger auf free-Zeiger trifft. 

• Bedingung: 

- komplett abgearbeitete Objekte, dürfen nicht auf noch nicht kopierte Objekte verweisen. 

• Erfolgt eine derartige Zuweisung, so muss das referenzierte Objekt sofort 

kopiert werden. 

� Zeigerzuweisungen überwachen 

• z.B. der Compiler fügt für jede Zeigerzuweisung den Aufruf einer Laufzeitroutine 

ein. 

• Nachteil: 

- Überwachung von Zeigerzuweisungen ist teuer. 


4.7.7 Reference Counting 

• Jeder Speicherblock wird durch einen versteckten Referenzzähler erweitert 

und speichert die Anzahl der Referenzen auf ein Objekt 

• Ein Objekt ist Garbage, wenn der Referenzzähler null ist. 

• Zeigerzuweisung über Laufzeitfunktion: 

- In der Laufzeitroutine erfolgt Zeigerzuweisung und Inkrementierung des Referenzzählers. 

- Bei Zuweisung von „null“ wird der Referenzzähler erniedrigt. 

• Bei sehr vielen Referenzen auf ein Objekt soll der Zähler "kleben" bleiben. 

• Vorteile: 

- inkrementelle Freispeichersammlung möglich, 

- Garbage wird sofort freigegeben. 

- einfach implementierbar. 

• Nachteile: 

- Zyklen werden nicht erkannt. 

- Zeigerverwaltung erforderrt den 

Aufruf einer Laufzeitroutine 

1 

1 

2 

1 

1 

1 

1 

1 

Garbage 


1

4.7.8 Backchain 

• Ursprünglich in Plurix verwendet. 

• Jeder Speicherblock führt eine 

Backchain, eine Liste der Referenzen, 

welche auf ihn zeigen. 

• Im Falle einer Allozierung („new“) wird 

der zugeordnete Zeiger in die Liste 

eingetragen. 

• Wird eine Zeigervariable freigegeben, 

wird sie aus der Backchain entfernt. 

Backchain 

Referenzen 

Heap Objekt 

• Wird ein gültiger Zeigerinhalt einer anderen Referenz zugewiesen (assigned), 

so wird auch dieser Zeiger eingetragen. 

• Freispeichersammlung sammelt nun alle Blöcke mit leerer Backchain ein. 

• Im Prinzip eine Abwandlung der Reference Counting Technik. 


• Heap-Kompaktierung: 

- Dynamische Relozierung von allozierten Blöcken. 

- Zeiger mit Hilfe der Backchain anpassen. 

• Vorteil: 

- inkrementelles Sammeln möglich. 

- Heap kann kompaktifiziert werden. 

- Zeiger einfach & eindeutig 

identifizierbar. 

• Nachteil: 

Objekt 

- Zyklen werden nicht erkannt. 

- Referenzen sind doppelt so groß. 

- Austragen von Zeigern teuer � O(n). 

- Zeigerverwaltung kostet Aufruf von Laufzeitfkt. 

• Backpacks als Weiterentwicklung der Backchain: 

- Mehrzahl der Backlinks werden in-line untergebracht, 

- Weitere Backlinks liegen in separaten Heap-Blöcken, 

- Progressiv wachsende Containergrösse für die Backpacks. 

Backpacks 

Backlinks

Hauptspeicher - Universität Ulm

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?