1 / 21

6.6 Persistenter virtueller Speicher

6.6 Persistenter virtueller Speicher. Idee: alle Segmente sind persistent  „Datei“-Begriff überflüssig ! Aber: Segment hat erweiterten Deskriptor.  Segment überdauert  Tod des erzeugenden Prozesses,  Systemabschaltung,  Systemabsturz,

kirk-underwood
Download Presentation

6.6 Persistenter virtueller Speicher

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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)

  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

  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)

  5. Berechtigungen Deskriptoren für Objektefür Datensegmente für Codesegmente x c „Objekt x vom Typ c“

  6. Codesegment beginnt mit Sprungleiste: 8: 125: JUMP 0008 JUMP 0125 JUMP 4711 JUMP .... JUMP .... JUMP .... JUMP .... JUMP ....

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

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

  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

  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.

  11. 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 ?

  12. 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)

  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!)

  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)

  15. MONADS Software (Newcastle, Bremen, Ulm [Keedy et al.]) • realisiert damit objektbasierten, persistenten Adressraum: •  Module Capability: module handle rights meta-rights •  keinmap – 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 )

  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“))

  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.

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

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

  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äßigatomarer Vorgang ist.

  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äßigatomarer 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

More Related