dr. welf löwe und markus noga1 verteilte speicherbereinigung problem –verteilung von komponenten...

Dr. Welf Löwe und Markus Noga 1

Verteilte Speicherbereinigung

Problem– Verteilung von Komponenten– Bezüge auf ferne Komponenten möglich– Wann löschen?

Ansätze– Explizit durch Benutzer vorgeben

• Verlagert das Problem, löst es nicht• In klassischen Sprachen (C, C++) häufigste Fehlerquelle!

– Automatisch durch Laufzeitsystem• Korrektheit• Effizienz?

Modell aufstellen


Modell

Ein verteiltes System besteht aus diskjunten (Adress-) RäumenRäume kommunizieren über Nachrichten– Mögliche Probleme der Nachrichten

• Verdopplung • Vertauschung• Verlust

Ein Raum enthält– Komponenten– Bezüge auf (lokale und) ferne Komponenteninstanzen

Bezüge nur auf Instanzen exportierter Komponenten


Modell

Raum Raum Raum

Komponenteninstanz

Komponenteninstanz

Komponenteninstanz

Komponenteninstanz

Schlüssel Bezug

Schlüssel Bezug

Bezug


Operationen auf Bezügen

Anlegen– Besitzer einer Komponenteninstanz sendet Bezug– ggf. Schlüssel erzeugen

Duplizieren– Inhaber eines Bezuges kopiert ihn– Sendet an fremden Raum

Löschen– Manuell– Automatisch durch Speicherbereinigung

Austausch von Nachrichten zwischen Räumen als Implementierung


Kriterien für Verfahren

Erkennen von Zyklen– Transitive Selbstbezüge ohne Einstieg über Bezug aus aktivem

Programm– Über Räume hinweg

SkalierbarSicherheit gegen Ausfall von RäumenResistent gegen Probleme mit Nachrichten– Verdopplung– Vertauschung– Verlust

Implementiert


Überblick

Klassisches TracingReferenzzählen– naiv– gewichtet

ReferenzlistenHybridverfahren– Migration von Objekten– Probelöschen

Verteiltes Tracing– Zeitstempel


Klassisches Tracing

System anhaltenLokal lebendige Komponenten markierenAlle von ihnen global erreichbaren Komponenten markierenNicht markierte Komponenten freigebenTheoretisch einfach, praktisch unbrauchbar. Leistung furchtbar.

Raum

Komponente

Schlüssel


Naives Referenzzählen

Anzahl der Bezüge B im Schlüssel zählenFreigabe wenn B=0 Nachricht an Besitzer bei Duplizieren und LöschenNachteile– Zyklen nicht erkennbar– Falsche Freigabe bei

• Verdopplung Löschen• Vertauschung

Duplizieren/Löschen• Verlust Duplizieren

– Falsches Behalten bei• Verlust Löschen

Raum

Komponente

Schlüssel B=1


Raum

Gewichtetes Referenzzählen

Gewicht des Schlüssels WTeilgewicht der Bezüge Ti

W= Ti

Löschen bei W=0Nachricht nur bei LöschenDuplizieren: Ti aufteilen

Vorteile– Weniger Nachrichten– Verträgt Vertauschung

Probleme– keine Zyklenerkennung– Falsche Freigabe u. Behalten– Neu: Aufteilbarkeit

Raum

Komponente

Schlüssel W=1.0

BezugT=0.5


Mögliche Verbesserungen

Optimiertes gewichtetes Referenzzählen– Invariante abschwächen: W Ti– Wenn Teilgewicht nicht aufteilbar, auf 0 setzen– Gelegentlich anderes Verfahren einsetzen, das ursprüngliche

Invariante wiederherstellt (z.B. klassisches Vorgehen)– Verbesserung

• Aufteilung von Teilgewichten• Verträgt Verlust von Nachrichten• Vorteile des anderen Verfahrens

Indirektes gewichtetes Referenzzählen– Einführen indirekter Schlüssel– Verbesserung

• Aufteilung von Teilgewichten


Raum 2

Referenzlisten

Menge aller Benutzer B im Schlüssel speichernLöschen bei B=Nachricht bei Duplizieren und LöschenVorteile– Verträgt Verdopplung– Raumausfall behandelbar

Nachteile– Viele Nachrichten– Verlust, Vertauschung ungelöst

Raum 1

Komponente

Schlüssel B={2, …}

Bezug


Hybridverfahren: Migration

Annahmen– Referenzzählen oder

Referenzlisten– Lokale GC

Idee– Migriere lokal tote, global

lebendige KomponentenVorteil– Globale Zyklen werden lokal

und von der GC beseitigtProbleme– Umgang mit Indirektionen– Migration u.U. unmöglich

Raum

Raum

K 1

K 2

K 2


Hybridverfahren: Probelöschen

Annahme– Referenzzählen oder Referenzlisten– Heuristik für tote Komponenten (z.B. lokale GC)

Idee– Lösche vermutlich tote Komponenten probeweise– Prüfe ob dabei alle Referenzen verschwinden

Vorteil– Globale Zyklen werden erkannt

Probleme– Konkurrierende Probelöschungen– Steht und fällt mit Heuristik


Tracing mit Zeitstempeln

Annahme– Globaler Dienst zur Zeitabstimmung

Idee– Objekte mit Zeitstempeln markieren– Lokale GC propagiert sie entlang der Bezüge– Tote Komponenten haben alte Zeitstempel

Vorteil– Nur lokales Anhalten– Globale Zyklen werden erkannt– Verträgt Vertauschung und Verdoppelung

Nachteil– Abstimmungsdienst skaliert schlecht– Ausfall eines Raums macht lokale GC unmöglich– Verlust von Nachrichten ungelöst


Beispiel: Tracing mit Zeitstempeln

Raum 2

Raum 3Raum 1

ZeitabstimmungR={1,2,3,…}

f: RTminRf

Kt=2

Kt=3

Kt=1

Kt=2

Kt=3

Kt=2



Raum 2

Raum 3Raum 1


f: RTminRf

Kt=2

Kt=3

Kt=4

Kt=2

Kt=3

Kt=2

f(1)=4, minRf=2

t=4



Raum 2

Raum 3Raum 1


f: RTminRf

Kt=2

Kt=3

Kt=4

Kt=4

Kt=3

f(2)=5, minRf=3t=4



Raum 2

Raum 3Raum 1


f: RTminRf

Kt=4

Kt=3

Kt=4

Kt=4

f(3)=6, minRf=4



Raum 2

Raum 3Raum 1


f: RTminRf

Kt=2

Kt=7

Kt=4

f(1)=7, minRf=5

t=7


Mögliche Erweiterungen

Hierarchie einführen– Skaliert besser

Übergang zu Zeitlisten– Ein Zeitstempel pro benutzendem Raum– Ausfall von Räumen bewältigbar

Bündelung von Updates– reduziert Anzahl der Nachrichten


Bewertung

Zyklen Skaliert Raum-ausfall

Verdop-pelung

Vertau-schung

Verlust Impl.

Referenzzählen

gewichtet

Referenzlisten

Hybride () ()

Zeitstempel () n.a n.a n.a


Industrielle Praxis

COM, Corba– Referenzzählen

Enterprise JavaBeans– Lokale GC

Transportkanal sichert gegen – Verlust– Verdopplung– Lokale Vertauschung

Entwurf muß absichern gegen– Globale Vertauschung– Zyklen

Z.B. durch Schichtenmodell

Aktive verteilte DokumenteEine XML-basierte Architektur

Markus L. NogaDoktorandenseminar IPD

29.6.2001


Was bisher geschah

Bisher– Komponenten zentrales Konzept– Daten untergeordnet

Jetzt duale SichtBeschreibung von XML Daten– XML Schema

Erweiterung auf Komponenten– Negativbeispiel: WSDL

Kommunikation via XML– Negativbeispiel: SOAP

Referenzen auf Komponenten


Ziel

Vereine Daten und KomponentenAktive verteilte Dokumente– Statische Daten– Dynamische Generatoren– Verteilung– Bearbeitung


Kriterien

Erweiterbare Dokumente– K1 Erweiterbar, hierarchisch organisiert– K2 Transparente Erzeugung von Teilen

Benutzbarkeit– K3 Inkrementelle Bearbeitung– K4 Typen und Validierung– K5 Benutzerfreundlich

K6 Transparente Verteilung

Erweiterbare DokumenteBenutzbarkeitTransparente Verteilung


Gliederung

Stand der Technik– Basistechnologie– Verwandte Anwendungen

Architektur– Domäne– Schichten

Technische FragenAusblick


Stand der Technik

Basistechnologie (bekannt)– XML Schema– SOAP– DOM

Verwandte Anwendungen– Textverarbeitung– Tabellenkalkulation– Das Netz– Industrielle Komponentensysteme


Textverarbeitung

Löst: Lokale Bearbeitung von TextenVertreter: Microsoft WordErweiterbare hierarchische DokumenteGeneratoren nicht transparentInkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichKeine Verteilung


Tabellenkalkulation

Löst: Aktives lokales DokumentVertreter: Microsoft ExcelStarre DokumenteGeneratoren transparentInkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichKeine Verteilung


Das Netz

Löst: Verteiltes Lesen von DokumentenVertreter: HTTP/HTMLErweiterbare hierarchische DokumenteGeneratoren nicht für TeileKeine inkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichVerteilt


Komponentensystem

Löst: Verteilung von KomponentenVertreter: Corba, COM, EJBKein Begriff des DokumentsStarke TypisierungNur von Experten verwendbarVerteilt


Stand der Technik: Fazit

System K1 K2 K3 K4 K5 K6

Textverarbeitung

Tabellenkalkulation

Das Netz

Komponenten


Architektur: Betrachtete Domäne

Aktive verteilte Dokumente sind Wälder von KnotenKnoten sind typisierte Behälter– Werte– Teilbäume– Generatoren für Werte– Generatoren für Teilbäume

Uniform referentTransparent gegenüber Verteilung


Schichten

EditorsEditors

Bidirectional XML Transport Protocol

DOM / Generators

DOM / Values

User InterfaceEditors


Transportprotokoll

Anforderungen– Feingranular– Bidirektional – Änderungspropagation

Konstruktion– Erweitere URL um Feinadressierung– Expliziter Kontext im Rückkanal– Komplementiere Pull mit Push


DOM mit Generatoren

Erweiterung des DOMGeneratorknoten kapselt– Verweis– Abfrage (z.B. XPath)– Transformation (z.B. Untermenge XSLT)– Programm

Jeweils verteiltGenerator ist BlattKeine Typen


DOM mit Werten

Schnittstelle ist DOM Generatoren durch Werte ersetztDynamische Aktualisierung– bei Änderung der Quelle– bei Änderung der Sicht

• wo technisch möglich• wo zulässig

Typen und Validierung


Benutzerschnittstelle

Allgemeiner XML-Editor– Visualisierung als Baum, Text etc.

Dynamischer Wechsel zwischen– Generatorensicht– Wertesicht

Einbettung spezieller Editoren nach– Elementtyp– Benutzereinstellungen


Spezielle Editoren

DOM/V nutzt– Werte– Dyn. Verbindung

DOM/G zusätzlich– Generatoren– Schachtelung

Beispiele– Read: HTML, SVG– Write: Tabelle

Writ

e

DOM/V

Read

DOM/G

Edit

View

SmartEdit

Smart View


Technik: DOM Operationen

DOM ist attributierter BaumVollständige Operatormenge– Knoten einfügen– Knoten löschen– Attribute ändern

Für die Praxis zusätzlich– Cut/Paste von Teilbäumen

Semantik, Umsetzung klar


Semantik auf DOM/V

Einfügen– Was?– Wo?

Löschen– Was?

Ändern– Was?

Auswirkungen propagieren

Generatoren– Verweis– Abfrage– Transformation– Programm

Abbildung i.A.– nicht umkehrbar– nicht hinreichend


Zyklische Bezüge

Führen in unendliche RekursionVermeidung nicht möglichErkennen– Verteilung stört traditionelle Ansätze– Nutze Erkenntnisse der verteilten GC?

Auflösen– Dem Nutzer überlassen– Fixpunkt-Iteration?


Werden die Kriterien erfüllt?

System K1 K2 K3 K4 K5 K6

Textverarbeitung

Tabellenkalkulation

Das Netz

Komponenten

Aktive Dokumente


Ausblick

Berücksichtige Erkenntnisse aus– Attributgrammatiken– Funktionalen Sprachen

Verfeinere Architektur– Schnittstellen der Schichten– Zusammenspiel

Beachte Einsatz von– Standardwerkzeugen– Eigenentwicklungen des IPD

Umsetzen– mit Ihrer Hilfe?


Fazit der Veranstaltung

1. Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)

2. Industrielle Komponentensysteme der 1. Generation1. CORBA 2. Enterprise JavaBeans3. (D)COM

3. Anpassungen – Daten und Funktion– Interaktion

• Kommunikation• Synchronisation• Protokolle

– Lebendigkeit


Einführung

Definition– Programmeinheiten mit standardisierter Basiskommunikation– Standardisierte Verträge für Wiederverwendung– Anpassungen nötig

Immer zusammen zu betrachten – Komponente und – Wechselnde Umgebungen

Unterscheidung– Statische Komponente (Programm oder Spezifikation)– Dynamische Instanz einer Komponente


Einführung

Objektorientiertes Programmieren– Bibliotheken– Frameworks

Aspektorientiertes Programmieren– Sichten auf ein System (Abstraktion) unterschiedlich beschreiben– Weben des Systems (Konkretisierung) oft unklar

Architektursysteme– Begriff der Ports– Programmpunkte zur Adaption der Kommunikation

Metaprogrammierung– Uraltes Konzept: Programme sind Daten (bekannt seit Lisp)– Methode zur Anpassung von Komponenten


Klassische Komponentensysteme

Wie Männer - Im Prinzip alle gleichGelöste Probleme– Verteilung von Komponenten– Kommunikation über Standardschnittstellen

• Stub und Proxy• Verteilte Referenzen

– Heterogene Komponenten und Komponentensysteme

Ungelöste Probleme– Anpassungen– Entwurf


Anpassungen

Daten– XML zur Datenbeschreibung– XSLT zur Transformation

Funktionalität– Umwickeln der Komponenten (wrapper)– Einmischen der Wrapper mit Metaprogrammierung

Kommunikation und Synchronisation– Erkenne Kommunikations- und Synchronisationspunkte– Beschreibe sie abstrakt– Konkretisierung durch Metaprogramm

Protokolle und Lebendigkeit– Dynamisch – Statisch schwierig, da aufwendige Analyse nötig


Offene Probleme

Entwurf von Komponentensystemen– Vordefinierte Komponenten– Nichtfunktionale Leistungskriterien (Bandbreite, Verfügbarkeit, etc.)

Re-Engineering von Altsystemen– Erkennen von Komponenten und Kommunikation in Altsystemen

• Profiling und Metriken• statische Analysen • Visualisierung von Software

– Anpassungen

Lernkurve senken– Bessere Bücher für Einsteiger– Dokumentation generieren

Studien- / Diplomarbeiten im EU Projekt EASYCOMP Dynamic

Composition

ComponentModels andSpecification

Process Support

Case Studies

Case Studies

Case StudiesC

ase

Stud

ies

Aspect-basedComposition

CompositionConsistencyChecking

CompositionTechnology

EasyComp

Komponenten

Repräsentation

Verarbeitung & Komposition

Verifikation

Interesse?Ansprechperson: Elke Pulvermü[email protected] oder Geb.50.41 (AVG), 2.OG


Studien- und Diplomarbeiten

XML und Webkomponenten in einem Industrieprojekt– SOAP, WSDL, UDDI etc.– .NET und EJB– Castor– XML Protocol, ...

XML und GUI Building– Uniforme Beschreibung von GUIs mit XML– Abbildung auf das Web und klassische APIs

• HTML Formulare (via XSLT)• Java/Swing (Codegenerierung oder Werkzeuganbindung)

Ansprechpartner: Löwe und Nogaloewe|[email protected] Geb.50.41 (AVG), 2.OG

dr. welf löwe und markus noga1 verteilte speicherbereinigung problem –verteilung von komponenten...

Documents