6.6 Persistenter virtueller Speicher Idee: alle Segmente sind persistent  „Datei“-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor. bs-6.5

 Tod des erzeugenden Prozesses,  Systemabschaltung,  Systemabsturz,  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

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

 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

Berechtigungen Deskriptoren für Objekte für Datensegmente für Codesegmente x c „Objekt x vom Typ c“ bs-6.5

Codesegment beginnt mit Sprungleiste: 8: 125: JUMP 0008 JUMP 0125 JUMP 4711 JUMP .... bs-6.5

CALL(objCap, opNo, args) ohne Code/Daten-Adressen, Objektaufruf: CALL(objCap, opNo, args) ohne Code/Daten-Adressen, wohl aber Berechtigungen! Objektrücksprung: RETURN bs-6.5

Typisches Sharing-Szenario: Prozess P Prozess Q P-Keller Q-Keller ObjektX ObjektY ObjektZ CodeC CodeD Code Sharing Object Sharing

 Shared Libraries: jede Bibliothek in eigenem Adressraum 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

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

Folgerung: unendlicher Adressraum wäre schön –  hat Platz für beliebig viele Segmente,  erlaubt Verzicht auf Wiederverwendung virtueller Segmente (!), die mit technischen und Sicherheitsproblemen verbunden ist. ? Was leisten 64-Bit-Adressen ? ? Braucht man 128-Bit-Adressen ? bs-6.5

adressierbar sind 264  16 * 1018 Bytes, 64-Bit-Adressen: adressierbar sind 264  16 * 1018 Bytes, Segmenterzeugung mit Rate 1000/sec à 106 Bytes verbraucht pro Sekunde 109 Adressen, Pro Tag (86400 sec) werden damit weniger als 1014 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

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

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

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

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

 regelmäßige Sicherungs-Operation hinterlässt 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

Sicherungs-Operation: Die erste Seite der Seitentabelle wird durch ihre shadow page ersetzt – im Arbeitsspeicher und auf der Platte. bs-6.5

Sicherungs-Operation: Die erste Seite der Seitentabelle wird durch ihre shadow page ersetzt – im Arbeitsspeicher und auf der Platte. shadow pages bs-6.5

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

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: bedeutet: wurde nicht vollständig geschrieben! n-1 n-1 n n-1 bs-6.5