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!