bs-6.5 1 6.6 Persistenter virtueller Speicher Idee: alle Segmente sind persistent „Datei“-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor.
bs-6.5 1
6.6 Persistenter virtueller Speicher
Idee: alle Segmente sind persistent
„Datei“-Begriff überflüssig !
Aber: Segment hat erweiterten Deskriptor.
bs-6.5 2
Segment überdauert
Tod des erzeugenden Prozesses,
Systemabschaltung,
Systemabsturz,
solange es über eine Berechtigung oder einen Namen
erreichbar ist (sonst Speicherfreigabe!).
Problem: Inter-Segment-Adressierung
Lösung: - entweder objektbasierte Adressräume ( 6.6.1)
- oder „unendliche“ Adressräume ( 6.6.2)
bs-6.5 3
6.6.1 Objektbasierte Adressräume
(z.B. in DAS (TU Berlin 1974-78), Clouds (Georgia Tech 1977-85),Birlix (GMD Birlinghoven 1985-89), u.a.)
minimale Segmentstruktur, z.B. lediglich
Code, Daten, Keller
Modul oder Objekt
oder Code, Moduldaten, Objektdaten, Keller
Objekt
bs-6.5 4
Objektidentifizierung über Berechtigung
Objektaufruf/rücksprung
bewirkt Wechsel des Adressraums
unter Beibehaltung des Kellers,
ist Mikrokern-Systemaufruf
in prozedurorientierter Architektur
(kein technischer Unterschied zwischen
Benutzer- und Systemobjekten)
bs-6.5 5
Berechtigungen Deskriptoren
für Objekte für Datensegmente für Codesegmente
cx
„Objekt x vom Typ c“
bs-6.5 6
Codesegment beginnt mit
Sprungleiste:
8:
125:
JUMP 0008JUMP 0125JUMP 4711JUMP ....JUMP ....JUMP ....JUMP ....JUMP ....
bs-6.5 7
Objektaufruf:
CALL(objCap, opNo, args)
ohne Code/Daten-Adressen,wohl aber Berechtigungen!
Objektrücksprung:
RETURN
ObjektX
Typisches Sharing-Szenario:
Prozess P Prozess Q
P-Keller
CodeC CodeD
Q-Keller
ObjektZObjektY
Code Sharing
Object Sharing
bs-6.5 9
Beispiele:
Shared Libraries: jede Bibliothek in eigenem Adressraum
Text“datei“? In der Regel ineffizient – daher Aufweichung
der starren Segmentierung: zusätzlich freie Datensegmente
(greifbar über Berechtigungen, map/unmap)
Parameterübergabe bei CALL/RETURN
kann Berechtigungen für Objekte
und freie Segmente beinhalten
bs-6.5 10
6.6.2 „Unendliche“ Adressräume
Wünschenswert:
freie Inter-Segment-Adressierung ermöglichen
Adressraumwechsel vermeiden
Segmentkollisionen im Adressraum vermeiden
Realisierung:
Jedem realen Segment ist ein eigenes virtuelles
Segment – für alle Prozesse! – zugeordnet.
bs-6.5 11
Folgerung: unendlicher Adressraum wäre schön –
hat Platz für beliebig viele Segmente,
erlaubt Verzicht auf Wiederverwendung virtueller Segmente (!), die mit technischenund Sicherheitsproblemen verbunden ist.
? Was leisten 64-Bit-Adressen ?
? Braucht man 128-Bit-Adressen ?
bs-6.5 12
64-Bit-Adressen:
adressierbar sind 264 16 * 1018 Bytes,
Segmenterzeugung mit Rate 1000/sec à 106 Bytesverbraucht pro Sekunde 109 Adressen,
Pro Tag (86400 sec) werden damit weniger als1014 Adressen verbraucht,
16*1018 / 1014 = 16*104
Adressen reichen für mindestens 160 000 Tage.
! Für netzweite Adressräume verteilter Systeme wurden
sogar schon 128-Bit-Adressen realisiert
(MONADS, Univ. of Newcastle, Australien, 1986-94)
bs-6.5 13
Typische Charakteristika unendlicher Adressräume:
Berechtigungen für Segmente, map/unmap
Seitentabellen auslagerbar
(Seitentabelle entspricht file map im Dateideskriptor!)
integrierte Speicherbereinigung (für realen Speicher!)
bs-6.5 14
Beispiel MONADS Hardware:
128-Bit-Adressraum mit Paging
Segmente* nicht an Seitengrenzen gebunden
Capability-Register für capability-basierte Adressierung:
base length rights
R,W,X
* haben festes Format (control, capabilities, regular data)
bs-6.5 15
MONADS Software (Newcastle, Bremen, Ulm [Keedy et al.])
realisiert damit objektbasierten, persistenten Adressraum:
Module Capability:
module handle rights meta-rights
kein map – wegen capability-basierter Adressierung:
jeder Prozess hat gleichen Adressraum mit allen
existierenden Segmenten – kann aber nur diejenigen
Segmente ansprechen, für die er Berechtigungen hat.
(Berechtigung in Register laden map )
bs-6.5 16
6.6.3 Stabiler Speicher
(stable storage)
= durch Systemsoftware realisierter „virtual storage“
mit der Eigenschaft, sogar Hardware- und System-
zusammenbrüche unbeschadet zu überstehen –
im Gegensatz zum flüchtigen Speicher (volatile storage),
dem Arbeitsspeicher;
wird (natürlich) mit Hilfe des externen Speichers realisiert.
Voraussetzung: keine Plattenschäden (andernfalls Platten duplizieren („spiegeln“))
bs-6.5 17
Grundprinzipien:
regelmäßige Sicherungs-Operation hinterlässt
Platten in konsistentem Zustand (s.u.).
Nach Sicherung geänderte Seiten werden beim
Verdrängen auf neu bereitgestellte Platten-Sektoren
hinauskopiert („shadow pages“);
Seitentabelle wird entsprechend geändert –
und selbst entsprechend gesichert (da selbst
im virtuellen Speicher!).
Erste Seite der Seitentabelle und ihre shadow page
werden im Arbeitsspeicher gehalten.
bs-6.5 18
Sicherungs-Operation:
Die erste Seite der Seitentabelle
wird durch ihre shadow page ersetzt –
im Arbeitsspeicher und auf der Platte.
bs-6.5 19
Sicherungs-Operation:
Die erste Seite der Seitentabelle
wird durch ihre shadow page ersetzt –
im Arbeitsspeicher und auf der Platte.
shadow pages
bs-6.5 20
Aktuell ist die gesicherte Version unter der Voraussetzung,
daß eine geänderte Seite möglichst bald verdrängt wird.
Korrekt ist dieses Verfahren unter der Voraussetzung,
daß das Schreiben eines Blocks auf die Platte ein
hardwaremäßig atomarer Vorgang ist.
bs-6.5 21
Aktuell ist die gesicherte Version unter der Voraussetzung,
daß eine geänderte Seite möglichst bald verdrängt wird.
Korrekt ist dieses Verfahren unter der Voraussetzung,
daß das Schreiben eines Blocks auf die Platte ein
hardwaremäßig atomarer Vorgang ist.
Falls nicht: 2 vergangene Versionen auf Platte halten – von denen die ältere garantiert konsistent ist:Versionierte Wurzelseiten:
n-1 n-1 n n-1
bedeutet: wurdenicht vollständiggeschrieben!