Strategien zur automatischen Objektmigration auf Grundlage ...

DIPLOMARBEIT
Strategien zur automatischen
Objektmigration auf Grundlage
statischer und dynamischer Analyse
Marco Weißenborn
marco.weissenborn@t-online.de
November 2003
Fakultät für Elektrotechnik, Informatik und Mathematik
Institut für Informatik
Arbeitsgruppe
Programmiersprachen und Übersetzer
vorgelegt bei:
Prof. Dr. Uwe Kastens
und
Prof. Dr. Odej Kao

VORWORT
An dieser Stelle bedanke ich mich bei all den lieben Menschen, die mich
während meines Studiums unterstützt haben.
Des Weiteren danke ich allen Menschen, die zum Gelingen dieser Arbeit einen
Teil beigetragen haben und möchte einige von Ihnen namentlich erwähnen.
Zunächst gilt mein Dank Prof. Dr. UWE KASTENS, der durch seine konstruktive
Kritik mir eine große Hilfe bei der Strukturierung der Arbeit war. Besonders
danke ich meinem Betreuer DINH KHOI LE, der mein Interesse an dieser
Diplomarbeit geweckt und mir immer mit Hinweisen und Ratschlägen
weitergeholfen hat. Für die vielen konstruktiven Diskussionen möchte ich mich
bei KARSTEN KLOHS bedanken.
Ein spezieller Dank geht an meine Freundin MARTINA EIBEN, die mich während
der Diplomarbeit motiviert und unterstützt hat.
Diese Diplomarbeit widme ich meinem Großvater Schmiedemeister ERICH
WEISSENBORN, der sehr gern studiert hätte, jedoch wegen der bescheidenen
Verhältnisse nach dem I. Weltkrieg nicht die Gelegenheit bekam. So begann er
eine Schmiedelehre und übernahm nach dem II. Weltkrieg den Handwerksbetrieb
seines Vaters.
ERKLÄRUNG
Hiermit versichere ich, dass ich diese Diplomarbeit selbständig und nur unter
Zuhilfenahme der angegebenen Quellen und Hilfsmittel angefertigt habe. Alle
wörtlich oder inhaltlich zitierten Stellen sind als solche kenntlich gemacht.
_______________________________
Paderborn, den 26. November 2003

KURZFASSUNG
Die verteilte Ausführung rechenintensiver Java-Anwendung
ist mit einer Steigerung der Ausführungsgeschwindigkeit
gegenüber der zentralen Ausführung
verbunden.
Die Steigerung der Ausführungsgeschwindigkeit kann
durch Einsatz von Migration und/oder Replikation in
Abhängigkeit von der Anwendung nochmals gesteigert
werden. Zur Berechnung von Situationen, in denen die
Migration und/oder Replikation von Objekten eine
Steigerung der Ausführungsgeschwindigkeit einbringt,
dienen Migrationsstrategien.
Herkömmliche Migrationsstrategien treffen ihre Entscheidung
über Migration, Replikation oder die Beibehaltung
der Platzierung eines Objektes auf Grundlage
dynamischer Programmanalyse-Ergebnisse.
Diese Diplomarbeit stellt ein Modell vor, das zusätzlich
auch noch die Nutzung von Ergebnissen aus statischer
Programmanalyse ermöglicht. Erste Messungen zeigen,
dass schon bei kleinen Anwendungen durch Migration
und/oder Replikation von Objekten Laufzeitvorteile
eintreten.

INHALTSVERZEICHNIS
1 Einleitung........................................................................................................ 1
2 Verwandte Arbeiten....................................................................................... 3
2.1 Verteilte Systeme......................................................................................3
2.1.1 JavaParty........................................................................................... 3
2.1.2 Doorastha.......................................................................................... 4
2.1.3 Juggle................................................................................................ 5
2.1.4 JOchestra...........................................................................................7
2.2 Migrationstrategien...................................................................................8
2.2.1 RepliXa............................................................................................. 8
2.2.2 Replikationsheuristiken für Verteilte Systeme............................... 11
2.3.3 Objektmigrationsstrategien in Verteilten Systemen....................... 13
2.3.4 Adaptive Objektmigration mit Neuronalen Netzen........................ 15
2.3 Capture-time based Thread Serialization................................................17
3 Vorüberlegungen.......................................................................................... 19
3.1 Migration und Replikation......................................................................19
3.2 Objektserialisierung................................................................................20
3.3 Parameter von Migrationsstrategien.......................................................22
3.4 Statische Programmanalyse.................................................................... 23
3.5 Dynamische Programmanalyse...............................................................25
4 Das JScatter-System.....................................................................................27
4.1 Transformation einer Java-Klasse.......................................................... 28
4.2 Transformator......................................................................................... 30
4.3 Laufzeitumgebung.................................................................................. 31
4.4 Verteilungsplan.......................................................................................32
5 Ein Modell für Migrationsstrategien..........................................................35
5.1 Transformation....................................................................................... 35
5.2 Migration und Replikation......................................................................36
5.2.1 Migration ........................................................................................36
5.2.2 Replikation......................................................................................42
5.3 Migrationsstrategien............................................................................... 45
6 Die Realisierung des Modells im JScatter-System.................................... 51
6.1 Transformation....................................................................................... 51
VII

INHALTSVERZEICHNIS
6.1.1 Erkennung migrierbarer und replizierbarer Objekte ......................51
6.1.2 Erweiterung des Transformationskonzeptes .................................. 52
6.1.3 Nutzung der statischen Programmanalyse zur Laufzeit .................55
6.2 Migration................................................................................................ 56
6.2.1 Methodenzugriffe ...........................................................................58
6.3 Replikation..............................................................................................59
6.3.1 Methodenzugriffe ...........................................................................60
6.4 Migrationsstrategien............................................................................... 62
7 Evaluation..................................................................................................... 65
7.1 Unterschiede bei Migration und Replikation .........................................65
7.2 Eine komplexere Migrationsstrategie.....................................................70
8 Zusammenfassung und Ausblick................................................................ 73
Literatur........................................................................................................... 75
Anhang A: Schnittstellen der Realisierung...................................................81
Anhang A.1: Instanzenanteil-repräsentierende Objekte...............................81
Anhang A.2: Klassenanteil-repräsentierende Objekte..................................82
Anhang A.3: Replikatgruppen-Objekte........................................................85
Anhang B: Transformationsbeispiele............................................................87
Anhang B.1: Instanzenanteil-repräsentierende Objekte............................... 87
Anhang B.2: Klassenanteil-repräsentierende Objekte..................................90
Anhang C: Basisimplementierung der Informationserfassung.................. 93
Anhang D: Laufzeitmessungen...................................................................... 95
Anhang D.1: Beispiel Post: Instanzenanteil................................................. 95
Anhang D.1.1: 10 Füllungen der Posttasche ...........................................95
Anhang D.1.2: 100 Füllungen der Posttasche..........................................97
Anhang D.2: Beispiel Post: Klassenanteil....................................................98
Anhang D.2.1: 10 Füllungen der Posttasche ...........................................98
Anhang D.2.2: 100 Füllungen der Posttasche..........................................99
Anhang D.3: Beispiel Bibliothek................................................................100
Anhang E: Beispielimplementierungen für Entscheidungsstrategien......103
VIII

1 EINLEITUNG
In den vergangenen Jahren wurde Java immer häufiger für wissenschaftliche
Berechnungen eingesetzt. Wissenschaftliche Berechnungen sind jedoch größtenteils
sehr umfangreich, so dass es von Vorteil ist, die entstehende Rechenlast
auf mehrere Rechner zu verteilten, um die Ausführungsgeschwindigkeit
der Berechnung zu erhöhen.
In der Projektgruppe ParJava [FFF+2002] wurde ein System zur Verteilung
von parallelen Java-Anwendungen entwickelt. Bevor eine Anwendung verteilt
ausgeführt werden kann, wird sie auf Bytecodeebene unter Einsatz statischer
Programmanalyse in eine verteilt ausführbare Anwendung transformiert.
Ein Problem der verteilten Ausführung ist jedoch, dass für Objekte, die häufig
von entfernt platzierten Objekten aus zugegriffen werden, ein enormer
Kommunikationsaufwand entsteht. Dieser Aufwand kann jedoch verringert
werden, wenn das zugegriffene Objekt sich auf dem Rechner befindet, von
dem aus die meisten Zugriffe auf das Objekt erfolgen. Diese Folgerung
resultiert aus der Feststellung, dass lokale Zugriffe kostengünstiger sind als
entfernte Zugriffe.
Zur Veränderung der Platzierung eines Objektes dient die Objektmigration.
Eine spezielle Form der Objektmigration stellt die Replikation von Objekten
dar. Durch Replikation ist es möglich, alle Zugriffe auf ein Objekt lokal
auszuführen, die den Zustand des Objektes nicht verändern. Zugriffe, die den
Zustand eines Objektes verändern werden Schreibzugriffe genannt.
Durch statische Programmanalyse kann schon vor der Laufzeit festgestellt
werden, an welchen Stellen einer Anwendung der Zustand eines Objektes zur
Laufzeit verändert wird. Somit stellt die statische Programmanalyse eine
Möglichkeit dar, Objekte einer Anwendung auf die wenige Schreibzugriffe
erfolgen zu identifizieren und zur Laufzeit zur Replikation vorzuschlagen.
Zusätzlich zur statischen Programmanalyse können jedoch mittels dynamischer
Programmanalyse auch Erkenntnisse über das Verhalten einer Anwendung zur
Laufzeit gewonnen werden.
Die Aufgabe von Migrationsstrategien ist, die Migration und/oder Replikation
von Objekten einer verteilt auszuführenden Anwendung so einzusetzen, dass
die Anzahl der entfernten Methodenzugriffe minimiert und somit die Ausführungsgeschwindigkeit
der Anwendung erhöht wird.
Herkömmliche Migrationsstrategien setzen für diese Berechnungen größtenteils
Informationen aus dynamischer Programmanalyse ein. Es gibt jedoch
auch Systeme, bei denen die Migrationsstrategie während der Implementierung
direkt vom Programmierer festgelegt wird. Solchen Strategien ist es jedoch
nicht möglich, auf Veränderungen der Rechenlast, beispielsweise durch
Veränderung der Anzahl der Rechner bei der Ausführung der Anwendung,
dynamisch zu reagieren.
1

KAPITEL 1 EINLEITUNG
Diese Diplomarbeit erweitert den Ansatz von Migrationsstrategien, die Informationen
aus dynamischer Programmanalyse nutzen, um die Nutzung von
Informationen aus statischer Programmanalyse. Hierbei wird die statische
Programmanalyse einerseits eingesetzt, um nur selten schreibend zugegriffene
Objekte zu identifizieren und Migrationsstrategien zur Laufzeit zur Replikation
vorzuschlagen. Andererseits wird sie eingesetzt, um den bei der Migration zu
übertragenden Objektzustand in Form der Felder des Objektes während der
Transformation der Anwendung zu ermitteln und spezielle Klassen zu generieren,
mit denen zur Laufzeit die Migration bzw. Replikation des Objektes
durchgeführt wird.
In Kapitel 2 werden verwandte Arbeiten im Zusammenhang mit Migration und
Replikation betrachtet. Hierbei wird zum Einen auf ausgewählte verteilte
Systeme, die Objektmigration und/oder Objektreplikation bei der Ausführung
von Java-Anwendungen unterstützen, eingegangen. Zum Anderen werden
verschiedene Migrations- bzw. Replikationsstrategien diskutiert. Abschließend
geht Kapitel 2 auf die Migration von Thread-Objekten ein.
Auf Vorüberlegungen, die im Zusammenhang mit Migrationsstrategien in
dieser Arbeit unerlässlich sind, wird in Kapitel 3 eingegangen. Hierzu gehören
eine nähere Betrachtung der Migration und Replikation von Objekten, die
Objektserialisierung, Parameter von Migrationsstrategien und die Betrachtung
von statischer und dynamischer Programmanalyse.
Kapitel 4 stellt das JScatter-System vor, in dem das entwickelte Modell für
Migrationsstrategien realisiert wurde. In Kapitel 5 wird auf das entwickelte
Modell für Migrationsstrategien näher eingegangen. Hierbei werden die
Erweiterung des Transformationskonzeptes für Migration und Replikation und
die Aufgaben von Migrationsstrategien näher vorgestellt.
Die Realisierung des Modells, dessen Besonderheiten bei der Serialisierung
sowie dessen Erweiterbarkeit, werden im Kapitel 6 beschrieben. Abschließend
wird in Kapitel 7 eine Evaluation der Implementierung an zwei Beispielsimulationen
vorgenommen und in Kapitel 8 eine kurze Zusammenfassung
durchgeführt sowie einige Vorschläge für die Weiterentwicklung des Systems
präsentiert.
2

2 VERWANDTE ARBEITEN
2 VERWANDTE ARBEITEN
In diesem Kapitel werden einige Arbeiten vorgestellt, die sich mit Teilgebieten
der Diplomarbeit beschäftigen. Zuerst werden einige ausgewählte Systeme
vorgestellt bevor Migrations- und Replikationsstrategien beschrieben werden.
Abschließend wird noch die Thread-Migration diskutiert.
2.1 Verteilte Systeme
2.1.1 JAVAPARTY
JavaParty [PZJ1998] ist eine Bibliothek zum Schreiben von verteilten
Anwendungen in Java. Hierfür erweitert es die Programmmiersprache um den
Modifier remote. Durch Verwendung des neuen Modifiers legt der Programmierer
fest, dass die Instanzen einer Klasse entfernt platziert werden
können. Diese Instanzen werden auch als remote objects bezeichnet.
JavaParty besteht aus einem Übersetzer und einem Laufzeitsystem. Der
JavaParty-Übersetzer generiert für jede Klasse einer in JavaParty geschriebenen
Anwendung, sieben Klassen und sechs Interfaces, ruft anschließend den
javac-Übersetzer auf und erzeugt unter Einsatz des RMI-Generators die für die
RMI-Kommunikation notwendigen Stub- und Skeletonklassen. Nach dem
Übersetzen kann das Programm im JavaParty-Laufzeitsystem ausgeführt
werden.
JavaParty unterstützt die Migration von Objekten und die Replikation
statischer Konstanten [PZ1997, Bor2002]. Wenn ein remote object auf einen
entfernten Rechner migriert wird, bleibt auf dem Ursprungsrechner ein
Stellvertreter zurück. Wird auf den Sellvertreter ein Zugriff ausgeführt, löst
dieser eine MovedException aus und gibt sie an das aufrufende Objekt
zurück. Mit der MovedException erfährt das aufgerufene Objekt die neue
Platzierung des migrierten Objektes und führt den misslungenen Zugriff ein
zweites mal auf das migrierte Objekt aus.
Als Stellvertreter eines remote objects dient in JavaParty ein sogenanntes
Handle. Über sie werden alle Zugriffe auf remote objects durchgeführt. Durch
das Weiterleiten der Zugriffe über Handles können alle Zugriffe auf remote
objects während dessen Migration solange aufgehalten werden, bis der Umzug
abgeschlossen ist.
Die Migration eines remote objects ist in JavaParty nur dann möglich, wenn
keine Methode auf dem zu migrierenden Objekt gerade ausgeführt und kein
anderes Objekt zum Zeitpunkt des Migrationswunsches migriert wird.
In JavaParty gibt es zwei unterschiedliche Möglichkeiten, das zu migrierende
Objekt neu zu platzieren. Bei der ersten wird das Objekt auf den Rechner
migriert, auf dem das zugreifende Objekt platziert ist. Als zweite Möglichkeit
kann ein beliebiger Rechner als neuer Platzierungsort gewählt werden, der
bereits ein remote object enthält. In beiden Möglichkeiten setzt JavaParty
3

KAPITEL 2 VERWANDTE ARBEITEN
folgende Migrationstechnik ein.
Zuerst beschafft sich das Handle die JavaParty-Repräsentation der lokalen
JVM des zu migrierenden remote objects. Anschließend wird dieses
LocalJVM-Objekt über einen Methodenaufruf dazu aufgefordert, das remote
object in seine Lokalität zu holen. Daraufhin initiiert das LocalJVM-Objekt das
remote object, mit der Migration zu beginnen. Dies prüft, ob die Migration
zum gegenwärtigen Zeitpunkt möglich ist. Ist die Migration durchführbar, wird
das remote object für weitere Zugriffe gesperrt und durch Objekt-Serialisierung
zu einem byte-Array konvertiert. Anderenfalls wird die Migration abgelehnt
und das bisherige remote object bleibt weiterhin gültig [Zen1997].
Ist das byte-Array auf dem neuen Rechnerknoten eingetroffen, wird aus ihm
ein neues remote object – also eine Kopie – erzeugt und ein Stub an das
Handle zurückgegeben. Das alte remote object und das Handle aktualisieren
ihren Stub und schließen somit die Migration ab. Von diesem Zeitpunkt an
leitet das veraltete remote object alle weiteren Methodenaufrufe an die Kopie
weiter.
Bei der Übersetzung einer in JavaParty geschriebenen Anwendung wird für
jede Klasse der Anwendung auch eine Klasse generiert, die den statischen
Anteil einer Originalklasse repräsentiert. Diese Klassen werden als remote
classes bezeichnet. Remote classes werden im JavaParty-Laufzeitsystem einmal
platziert. Eine Migration von remote classes ist jedoch nicht vorgesehen.
JavaParty verfügt über Verteilungsstrategien, die die Initialplatzierung eines
Objektes berechnen. Als Migrationsstratgie setzt es load-balancing ein. Durch
load-balancing werden migrierbare Objekte zur Laufzeit so platziert, dass alle
beteiligten Rechner ungefähr den gleichen Anteil der zu verrichtenden Arbeit
ausführen. Die Verteilungs-, wie auch die Migrationsstrategie ist austauschbar.
Hierfür wurden sie über das Entwurfsmuster Strategy [GHJV1995] realisiert.
2.1.2 DOORASTHA
Doorastha [Dah2000] ist wie JavaParty (siehe Abschnitt 2.1.1) eine Bibliothek
zum Schreiben von verteilten Anwendungen in Java. Es basiert auf der Idee,
eine zentrale Java-Anwendung durch Hinzufügen von speziellen Kommentaren
(Tags) zu verteilen. Doorastha verfügt ebenfalls über einen Übersetzer sowie
ein Laufzeitsystem. Beim Übersetzen einer kommentierten Anwendung ersetzt
der Doorastha-Übersetzer die Kommentare durch speziellen Code und generiert
für jede Klasse der Anwendung eine Wrapper-Klasse, eine Proxy-Klasse
sowie ein Interface. Nach anschließendem Übersetzen der Anwendung mit dem
javac-Übersetzer, ist sie im Doorastha-Laufzeitsystem ausführbar.
Die Proxy-Klasse dient als Stellvertreter für entfernte Zugriffe auf ein Objekt.
Ein Wrapper packt ein im Doorastha-Laufzeitsystem platziertes Objekt ein und
leitet alle von einem Proxy erfolgten Zugriffe an das umschlossene Objekt
weiter. Doorastha unterstützt Migration, Kopieren und die sogenannte Globa-
4

2.1 VERTEILTE SYSTEME
lisierung von Objekten. Ein globalisiertes Objekt kann im Doorastha-Laufzeitsystem
wie ein zentrales Originalobjekt referentiell zugegriffen werden.
Beim Kopieren von Objekten handelt es sich nicht um echte Replikation mit
Aktualisierung nach Schreibzugriffen, sondern um das Kopieren von Objekten,
wie es die RMI-Funktionalität von Sun [Sun2003] zur Verfügung stellt.
Durch Hinzufügen des entsprechenden Kommentars /*:globalizable*/, /
*:copyable*/ oder /*:migratable*/ bereitet der Programmierer eine
Klasse für die verteilte Ausführung seiner Instanzen vor. Beim Instanzieren
einer Klasse durch den new-Operator muss der Programmierer angeben, auf
welchen Rechner das Objekt instanziert werden soll, anderenfalls wird es lokal
platziert. Analog dazu gibt der Programmierer auch den Rechner an, auf den
ein Objekt zur Laufzeit migriert werden soll.
Auf diese Weise legt der Programmierer sowohl die Verteilungsstrategie als
auch die Migrationsstrategie beim Schreiben der Anwendung fest.
Analog zu JavaParty wird auch bei Doorastha eine MovedException beim
Zugriffsversuch auf einen Stellvertreter eines migrierten Objekts ausgelöst. Die
neue Platzierung des migrierten Objektes erhält das zugreifende Objekt über
die MovedException. Nach der Aktualisierung der Referenz wird der misslungene
Zugriff wiederholt.
Doorastha unterstützt die sogenannte schwache Thread-Migration, bei der das
Objekt nach der Migration explizit beliefert werden muss, um den Zustand des
Objektes an der neuen Platzierung wiederherstellen zu können. Wie in Abschnitt
2.3 beschrieben wird, ist diese Form der Thread-Migration jedoch mit
Informationsverlust verbunden.
2.1.3 JUGGLE
Juggle [SH1998] ist eine verteilte virtuelle Maschine für Java-Anwendungen,
die Objekte und Threads automatisch migriert und für eine ausgewogene Auslastung
der beteiligten Rechnerknoten sorgt. Mit Juggle kann eine beliebige
parallele Java-Anwendung auf mehreren Rechnern verteilt ablaufen. Sie setzt
Instrumentierung ein, um während des Programmablaufs ständig günstige
Platzierungen für Objekte und Threads zu errechnen. Die Umsetzung der errechneten
Konfigurationen wird unter Verwendung von Migration und Replikation
hergestellt.
Im Gegensatz zu JavaParty (siehe Abschnitt 2.1.1) und Doorastha (siehe Abschnitt
2.1.2) benötigt Juggle nur die übersetzte Java-Anwendung zur verteilten
Ausführung. Eine Transformation oder spezieller Code ist nicht notwendig.
Ähnlich wie in Distributed Shared Memory-Systemen (DSM) ist jedes Objekt
von allen beteiligten Rechnerknoten aus zugreifbar [SH1998]. Die gesamten
Objektdaten werden jedoch anders als bei DSM nicht zu dem zugreifenden
Knoten verschickt, sondern beim Zugriff auf eine Instanzvariable das entsprechende
Datum vom zugehörigen Rechnerknoten angefordert. Daher
5

KAPITEL 2 VERWANDTE ARBEITEN
können die Daten eines Objektes transparent migriert werden.
Objekte, die zur Laufzeit nur einmal modifiziert werden und auf die im Weiteren
voraussichtlich lediglich lesend zugegriffen wird, werden nicht migriert
sondern repliziert. Auf diese Weise enthält jeder Rechnerknoten seine eigene
Kopie der benötigten Objekte, wodurch zeitaufwändige entfernte Zugriffe
entfallen.
Juggle optimiert dynamisch und automatisch die Verteilung von Objekten, indem
es ein Maß für die Last der Threads auf die Objekte bestimmt. Hierbei
werden für jedes Objekt die Anzahl der Zugriffe aller Threads in einer festgelegten
Zeitspanne gezählt. Diese Anzahl dient als Maß für die Last der Threads
auf das Objekt. Juggle migriert ein Objekt immer zu dem Thread, der die
größte Last erzeugt. Auf diese Weise können die meisten Zugriffe auf das
Objekt lokal ausgeführt werden.
Durch dieses Verfahren wird die Anzahl der Zugriffe auf entfernte Rechnerknoten
stark reduziert. Während der gesamten Laufzeit überprüft das System
periodisch die Auslastung der Rechnerknoten und korrigiert sie gegebenenfalls.
Für diesen Vorgang werden die Korrelationen zwischen Threads und
Objekten berücksichtigt. Hierbei werden Threads, die auf die gleichen Objekte
Last ausüben, möglichst auf denselben Rechnerknoten bewegt. Somit wird
sowohl die Last auf die Rechenleistung, als auch die Anzahl der entfernten
Objektzugriffe minimiert.
Wie am Anfang des Abschnitts beschrieben, wird durch Instrumentierung festgestellt,
von welchem Rechner aus auf ein Objekt die größte Last ausgeübt
wird. Jedes Objekt hat hierfür einen Zeiger auf eine Datenstruktur, die den
Knoten beschreibt, auf dem sich das Objekt befindet. Ist das Objekt lokal, ist
der Zeiger NULL. Über weitere Zähler zählt jedes Objekt Zugriffe von lokalen
und entfernten Threads. Erreicht die Summe beider Zähler einen konfigurierbaren
Schwellwert, wird die Platzierung des Objektes neu bestimmt und gegebenenfalls
durch Migration oder Replikation angepasst. Ist die Anzahl der
Zugriffe von lokalen Threads größer als die Anzahl der Fernzugriffe, bleibt das
Objekt auf dem Rechnerknoten, auf dem es sich befindet, andernfalls wird
überprüft, ob eine Verlagerung des Objektes auf einen anderen Rechnerknoten
für das Gesamtsystem effizienter ist.
Damit Juggle ermitteln kann, von welchem Rechnerknoten aus wieviele entfernte
Zugriffe auf ein Objekt durchgeführt wurden, enthält jedes Objekt für
jeden Rechner einen zusätzlichen Zähler, der die entfernten Zugriffe jedes
Rechners zählt.
Juggle setzt Objektreplikation anstelle von Objektmigration ein, wenn die Anzahl
der Lesezugriffe nach einem Schreibzugriff einen konfigurierbaren Wert
überschreitet. Zum Zählen der Lesezugriffe wird ein weiterer Zähler verwendet,
der bei einem Lesezugriff um eins inkrementiert und bei einem Schreibzugriff
gelöscht wird. Soll ein Objekt migriert werden, wird überprüft, ob der
6

2.1 VERTEILTE SYSTEME
Lesezugriffs-Zähler den konfigurierbaren Wert für Migration überschreitet. Ist
dies der Fall, wird das Objekt repliziert. Bei der Replikation eines Objektes
merkt sich das System über ein Bitfeld, welche Rechnerknoten Replikate
besitzen. Bei einem Schreibzugriff auf ein Replikat werden diese Knoten
benachrichtigt und die Replikate gelöscht [SH1998]. Auf diese Weise
verhindert Juggle inkonsistente Objektzustände zwischen einem Original-
Objekt und seinen Replikaten.
2.1.4 JOCHESTRA
JOchestra [TS2002a, TS2002b] ist ein automatisches Partitionierungssystem
für Java-Anwendungen. Es transformiert die Klassen einer Java-Anwendung in
eine durch die Standard-JVM ausführbare verteilte Anwendung. JOchestra
besteht aus einem Klassifikator, einem Profiler und einem Transformator.
Unter Einsatz des Profilers und des Klassifikators legt der Benutzer die
Partitionierung fest, die anschließend durch den Transformator erstellt wird.
Bei der Klassifikation unterscheidet JOchestra zwischen anchored und mobile
Klassen. Eine Klasse ist anchored, wenn die Platzierung ihrer Instanzen nicht
verändert werden kann. Andernfalls ist eine Klasse mobile. Klassen deren
Methoden native Code enthalten, können bei der Transformation nicht
verändert werden. Sie werden in JOchestra als unmodifiable bezeichnet. Unter
Verwendung dieser Begrifflichkeiten stehen dem Benutzer bei der
Klassifikation der Klassen einer zu transformierenden Anwendung drei
Optionen zur Auswahl.
Anchored unmodifiable Klassen: Eine Systemklasse C ist anchored unmodifiable,
wenn sie nativen Maschinen-Code enthält, oder auf Referenzen von C-
Objekte zwischen modifizierbarem Maschinen-Code und Instanzen einer
anchored unmodifiable Klasse zugegriffen werden.
Anchored modifiable Klassen: Eine Klasse ist anchored modifiable, wenn es
eine modifizierbare Klasse der Anwendung ist, die eine anchored unmodifiable
Klasse erweitert.
Mobile Klassen: Mobile Klassen sind alle Klassen, die nicht in eine der
anderen beiden Kategorien fallen. Alle Klassen, die in purem Java geschrieben
sind und keine Systemklasse erweitern (außer java.lang.Object) sind
mobile Klassen. Auch Systemklassen können zu dieser Kategorie gehören,
wenn sie keinen nativen Maschinen-Code enthalten und von keiner anchored
unmodifiable Klasseninstanz zugegriffen werden oder auf eine solche
zugreifen.
Mit Hilfe des Profilers und des Klassifikators legt der Benutzer die Klassifikation
für jede Klasse der zu transformierenden Anwendung fest. Hierbei
überprüft der Klassifikator die Auswahl und schlägt dem Benutzer Veränderungen
vor, um eine gültige Partitionierung zu erstellen. Für mobile Klassen
muss der Benutzer außerdem eine Migrationsstrategie beschreiben, in der er
7

KAPITEL 2 VERWANDTE ARBEITEN
festlegt, wann und wohin das Objekt migriert werden soll. Zur Auswahl stehen
call-by-move und call-by-visit. Mit call-by-move wird das Objekt auf den
angegebenen Rechner migriert und behält seine neue Platzierung bei. Mit callby-visit
behält das Objekt nur solange die neue Platzierung bei, bis der Zugriff
abgeschlossen ist. Nach dem Zugriff migriert es zu seiner Ursprungsplatzierung
zurück [JLHB1988].
TILEVICH und SMANAGDAKIS heben hervor, dass das Erstellen einer Migrationsstrategie
keine triviale Aufgabe ist. Eine falsche Wahl hat eine ineffektive und
inkorrekte verteilte Anwendung zur Folge [TS2002a].
Neben der Migrationsstrategie muss der Benutzer auch die Initialplatzierung
aller Objekte bei ihrer Klassifikation festlegen. Instanzen von anchored
Klassen werden einmal platziert und behalten ihre Platzierung während der
gesamten Laufzeit der verteilten Anwendung bei. Auf diese Weise legt der
Benutzer in JOchestra die Verteilungsstrategie fest.
Bei der Transformation werden durch den JOchestra-Transformator Stellvertreter-Klassen
im Sourcecode-Format und Remote-Klassen in Bytecode erzeugt.
Die Stellvertreter-Klassen werden zum Abschluss der Transformation
übersetzt. Die Original-Klassen werden so transformiert, dass sie nicht mehr
die Klasse java.lang.Object sondern die Klasse java.rmi.server.
UniCastRemoteObject erweitern. Dies ist notwendig, da die transformierte
Anwendung über RMI kommuniziert.
2.2 Migrationstrategien
2.2.1 REPLIXA
In [JGK1999, Jäg1999] stellen JÄGER, GOLM und KLEINÖDER ein auf Reflektion
[Mae1987] basierendes Framework names RepliXa zur transparenten und
anpassbaren Replikation von Objekten vor. RepliXa verfügt zur Zeit nur über
ein Grundsystem, das noch vieler Erweiterungen bedarf [Jäg1999]. Jedoch
zeigt es für die Entwicklung von Replikationsstrategien einige interessante
Aspekte auf.
Das wesentliche Anliegen der Entwicklung war es, für Programmierer ein
einfaches, transparentes, anpassbares und offenes System zur Objektreplikation
zu entwickeln. Hierbei bedeuten
einfach: eine einheitliche und kleine Schnittstelle zur Nutzung der Dienste
anzubieten,
transparent: Objekte entwickeln zu können, ohne Kenntnis darüber, ob sie
in der Zukunft repliziert werden,
anpassbar: die Ausrichtung für neue Ausführungsumgebungen einzurichten
und neue Replikationsprotokolle möglichst orthogonal zur Anwendung
hinzufügen zu können,
offen: neue Replikationsstrategien problemlos integrieren zu können.
8

2.2 MIGRATIONSTRATEGIEN
RepliXa verfügt über einen Mechanismus zum selektiven Binden von
Replikationsstrategien an Objekte. Hierzu setzt es den Java-Interpreter metaXa
[Gol1997] ein. Beim selektiven Binden wird an jedes zu replizierende Objekt
(Basis-Objekt) ein sogenanntes Meta-Objekt gebunden. Jedes Meta-Objekt
kapselt in einem Strategie-Objekt die Verhaltensänderung des Basis-Objektes
bei seiner Replikation. Das dynamische Binden zur Laufzeit muss vom
Benutzer jedoch speziell vorbereitet werden.
Für einen entfernten Methodenaufruf setzt RepliXa einen eigenen RMI-Mechanismus
ein. Soll beispielsweise ein Objekt A eine Methode eines entfernt
platzierten Objektes B aufrufen, geschieht dies über einen Stellvertreter von B,
der im gleichen Adressraum wie A platziert ist (siehe Abbildung 2.1). Der
Aufruf einer Methode von B durch A wird über den Stellvertreter von B, dessen
Meta-Objekt und dem Meta-Objekt von B an B weitergeleitet. Das Ergebnis
des Aufrufes wird in entgegengesetzter Richtung zurückgegeben.
Abbildung 2.1: Ablauf einer Remote Methode Invocation in RepliXa
Für Objektreplikation stellt RepliXa eine aktive und eine passive Replikationsstrategie
bereit. Beide Strategien halten den Zustand einer Menge von
Objekten konsistent. Ihre Vorgehensweisen sind jedoch unterschiedlich.
1
2
3
4
5
6
7
8
Objek
t
Prozess A
Meta-Objekt B_Stellvertreter
Meta System
Basis System
Prozess B
Meta System
Basis System
1 Methodenaufruf an ein beliebiges
1 Replikat (also auch an einen Primary)
2 Weiterleiten an den Primary
3 Koordination mit anderen Methodenauf-
3 rufen
4 Weiterleiten an alle Replikate
5 Bearbeiten des Methodenaufrufes
6 Rückgabe der Ergebnisse an den Primary
7 Rückgabe des Ergebnisses an das
7 Replikat
8 Rückgabe des Ergebnisses an den
8 Aufrufer
Abbildung 2.2: Ablauf eines replizierten Methodenaufrufes
IPC
B_Stellvertreter A B
Primary Replikat
1
Replikat
Meta-Objekt B
9

KAPITEL 2 VERWANDTE ARBEITEN
Die aktive Replikationsstrategie geht von folgender Grundidee aus:
Wenn auf eine gegebene Menge von Objekten mit konsistentem
Zustand die gleiche Methode aufgerufen wird, dann befinden sich
nach der Ausführung der Methode alle Objekte wiederum in einem
konsistenten Zustand. Damit die Konsistenz der Objekte gewahrt
bleibt, werden Methodenaufrufe auf ein Objekt an alle anderen
Objekte der Menge weitergeleitet.
Damit auch bei synchroner Methodenausführung, bei der Realisierung der
Idee, keine inkonsistenten Zustände zusammengehöriger Replikate auftreten,
wurde eine spezielle Vorgehensweise entwickelt. Hierfür setzen JÄGER, GOLM
und KLEINÖDER einen sogenannten Primary für jede Gruppe von Replikaten ein.
Trifft bei einem Replikat ein Methodenaufruf ein, leitet er den Methodenaufruf
an seinen Primary weiter. Beim Eingang mehrerer Methodenaufrufe legt der
Primary die Reihenfolge der Abarbeitung fest. Anschließend leitet er die
Ausführung der Methodenaufrufe in der festgelegten Reihenfolge an alle
Replikate weiter (siehe Abbildung 2.2).
Ein weiteres Problem besteht, wenn bei der Abarbeitung des Methodenaufrufes
auf einem Replikat ein weiterer Methodenaufruf auf ein anderes Objekt
involviert ist (siehe Abbildung 2.3).
1
2
3
Abbildung 2.3: Problem des mehrfachen Methodenaufrufs
1 Replizierter Methodenaufruf
1 (vereinfachte Darstellung)
2 Teilweise Bearbeitung des
2 Methodenaufrufes
3 Verschachtelter Methodenaufruf
In RepliXa wird dieses Problem durch Koordinierung der Replikate über den
Primary gelöst (siehe Abbildung 2.4). Alle Replikate arbeiten die Methode bis
zu dem Punkt ab, an dem die Methode des involvierten Objektes aufgerufen
werden muss. Dann geben sie dem Primary ein Signal, dass sie die Stelle erreicht
haben. Der Primary wartet solange, bis er von allen Replikaten das
Signal bekommen hat und führt anschließend die Methode auf dem involvierten
Objekt aus. Nach dem Abarbeiten der involvierten Methode arbeiten die
Replikate nach Aufforderung durch den Primary die Methode weiter ab.
Die passive Replikationsstrategie erhält den konsistenten Zustand aller Replikate
auf einem anderen Weg. Jedes Replikat arbeitet die Methode ab und leitet
nur die Veränderungen an die anderen Replikate weiter. Hierbei entstehen jedoch
zeitweise inkonsistente Objektzustände zwischen den Replikaten.
Weshalb darauf geachtet werden muss, dass durch inkonsistente Replikate die
Gesamtausführung des Programms, im Gegensatz zur lokalen Ausführung der
10
Objekt Replikat Replikat Replikat
3
Objekt

2.2 MIGRATIONSTRATEGIEN
Anwendung, nicht verändert wird. Das Problem wurde in RepliXa wiederum
durch einen Primary gelöst, der die Zugriffe auf die Replikate koordiniert. Des
Weiteren wurde ein sogenannter Snooper geschaffen, dessen Aufgabe darin
besteht, den Primary zu überwachen. Fällt dieser aus, übernimmt der Snooper
die Aufgaben des Primarys. Diese Lösung basiert auf dem erweiterten DSM-
Algorithmus der in [BW1994] ausführlich beschrieben ist.
1
2
3
4
5
6
7
8
9
Objekt
A
Primary Replikat
1
Replikat
2
Objekt
B
Abbildung 2.4: Verschachtelter Methodenaufruf
2.2.2 REPLIKATIONSHEURISTIKEN FÜR VERTEILTE SYSTEME
1 Replizierter Methodenaufruf
1 (vereinfachte Darstellung)
2 Teilweise Bearbeitung des
2 Methodenaufrufes
3 Verschachtelter Methodenaufruf
3 (weiterleiten zum Primary)
4 Methodenaufruf durch Primary
5 Bearbeitung des verschachtelten
5 Methodenaufrufes
6 Rückgabe des Ergebnisses
7 Verteilung des Ergebnisses
8 Fortführung der Bearbeitung
8 des Methodenaufrufes
9 Rückgabe der Ergebnisse
Ziel dieses Abschnittes ist es, die von MAFFEIS und CAP in [MC1992] dargestellten
Replikationsheuristiken sowie Eigenschaften von Replikationsheuristiken
vorzustellen. MAFFEIS und CAP gehen davon aus, dass auf ein
Replikat nicht nur vom Rechner seiner Platzierung aus zugegriffen wird,
sondern, dass Replikate für Zugriffe eines gesamten Subnetzwerkes vorgesehen
sein können. Auf diese Weise kann durch wenige Replikate ein
gesamtes Netzwerk abgedeckt werden. Zugriffe erfolgen in solch einem
System immer auf das Replikat, das vom Zugreifer aus am nächsten platziert
ist.
Eine Objekt-Replikationsheuristik besteht aus einer Menge von Regeln die
festlegen, wann welches Objekt repliziert wird, und wo das neue Replikat zu
platzieren ist. Der Level einer Replikationsheuristik gibt an, wieviele Replikate
eines Objektes zur Laufzeit maximal im Netzwerk platziert werden dürfen.
Replikationsheuristiken dienen in Replikationssystemen als Kontrolleinheit,
die den Replikationslevel an die Veränderungen im verteilten System
dynamisch anpasst. Veränderungen finden durch Ereignisse, wie Knoten- oder
Gateway-Fehler, zerbrechen von Anfragen zwischen Objekten, erzeugen und
11

KAPITEL 2 VERWANDTE ARBEITEN
platzieren neuer Objekte im System, usw. statt [MC1992].
Das Anpassen des Levels einer Replikationsheuristik ist eine nicht triviale
Aufgabe. Wenn im Netzwerk auf jedem Rechner ein Replikat eines Objektes
vorhanden ist (Replikationslevel = Anzahl verfügbarer Rechner), dann
bestimmen die Anzahl der Rechner und der Datenverkehr im Netzwerk,
wieviel Zeit für das Aktualisieren aller Replikate eines Objektes, z. B. nach
einen Schreibzugriff auf das replizierte Objekt, benötigt wird. Dieses Problem
wird als TOO-MANY-REPLICAS-EFFECT bezeichnet.
Werden in einer solchen Situation verstärkt Schreibzugriffe auf ein Objekt
ausgeführt, dann hat das verteilte System hauptsächlich damit zu tun, die
Replikate des Objekte zu aktualisieren. MAFFEIS und CAP nennen dies
Distributed-Thrashing.
Wenn der Replikationslevel hingegen zu niedrig ist, müssen die Referenzen
zwischen einem Objekt und seinen Replikaten zu häufig aktualisiert werden,
wobei auch lange Wartezeiten für Datenverkehr-intensive Aufgaben auftreten
können. In einer solchen Situation müssen einerseits Maßnahmen ergriffen
werden, die die Leistungsfähigkeit des Systems verbessern, und andererseits
muss die Verfügbarkeit der im System platzierten Replikate erhöht werden.
Um die Leistungsfähigkeit zu verbesseren, muss der Datenverkehr gesenkt
werden. Um die Verfügbarkeit der platzierten Replikate zu erhöhen, müssen
neue Replikate im System platziert werden, was zu erhöhtem Datenverkehr
führt. Somit stehen sich die Maßnahmen konträr gegenüber. Dieses Problem
wird als TOO-FEW-REPLICAS-EFFECT bezeichnet.
MAFFEIS und CAP setzen sich in [MC1992] mit vier Replikationsheuristiken
auseinander, die im Folgenden vorgestellt werden.
NAIVE: Wenn von einem Rechner R auf ein Objekt O das erste Mal
zugegriffen wird, dann wird ein Replikat von O auf R platziert, und
in die Menge der lokalen Replikate auf R eingetragen. Eine obere
Replikationsschranke ist durch die Speicherkapazität des verteilten
Systems gegeben.
LIMIT: LIMIT arbeitet wie NAIVE, benutzt jedoch zwei Schranken für die
Replikation eines Objektes O. Die obere Replikationsschranke wird
mit OU (upper bound) und die untere mit OL (lower bound) bezeichnet.
LIMIT vermeidet Distributed-Thrashing wie auch TOO-FEW-
REPLICAS-EFFECT und sorgt dafür, dass die beiden Schranken an
die Veränderungen im System angepasst werden. Bei LIMIT ist es
möglich, für jedes Objekt verschiedene OU und OL festzulegen.
COUNT: Erst nach dem auf ein Objekt CO mal von R aus zugegriffen wurde,
wird auf R ein Replikat von O platziert. Diese Strategie ist für
Systeme geeignet, bei denen eine große Anzahl von Objekten nur
selten von einem entfernten Rechner im Netzwerk zugegriffen wird.
12

2.2 MIGRATIONSTRATEGIEN
Im Gegensatz zu NAIVE und LIMIT, bei denen exzessiv kopiert und
migriert wird, werden hier nur wenige Replikate erstellt. Wie in
LIMIT gibt es auch in COUNT obere und untere Replikationsschranken.
Des Weiteren enthält COUNT Zähler zum Zählen der
Zugriffe auf ein Objekt, die von Zeit zu Zeit auf ihren Initialwert
zurückgesetzt werden.
INTENSITY: INTENSITY baut auf COUNT auf. Sie lässt die Replikation von
O jedoch nur zu, wenn die CO Zugriffe während eines Zeitintervalls
I eingetroffen sind. Des Weiteren stellt INTENSITY
Mechanismen für den Umgang mit zerbrochenen Anfragen
zwischen Objekten bereit.
2.3.3 OBJEKTMIGRATIONSSTRATEGIEN IN VERTEILTEN SYSTEMEN
In verteilten Systemen setzen sowohl Lastverwaltungssysteme als auch verteilte
Betriebssysteme Objektmigration ein, um eine Leistungsverbesserung zu
erreichen. Hierbei soll vor allem die Rechenlast der über ein Netzwerk
verbundenen Rechner möglichst gleichmäßig verteilt werden. Lastverwaltungssysteme
und verteilte Betriebssysteme setzen zum Erreichen des Lastausgleichs
größtenteils Prozessmigration ein.
In Lastverwaltungssystemen wird hierbei versucht, echte Lastbalancierung
zwischen den im Netzwerk vorhandenen Rechnern zu erreichen. Dabei gehen
einige Lastverwaltungssysteme davon aus, dass die eigentliche Migration vom
Betriebssystem unterstützt wird [Lux1995]. Im verteilten Betriebssystem Birlix
[Lux1995] werden neben Prozessen auch Dateien und nicht aktive Objekte
migriert.
Mit den Aufgaben von Objektmigrationsstrategien in verteilten Systemen
beschäftigten sich GERNS und LIE im Rahmen des Projektes DIOMEDES
(Design and Implementation of an Object Migration System for Performance
Enhancements in Distributed Environment) [GL1994]. Hierbei fanden sie
heraus, dass Migrationsstrategien Informationen über die Last der Rechner in
Netzwerken sammeln, die gesammelten Informationen auswerten, eine Entscheidung
treffen wie die Lastsituation verbessert werden kann und die Entscheidung
unter Einsatz von Migration durchführen. Anschließend überprüfen
sie, wie ihre Entscheidung die Lastsituation verändert hat und führen einen
neuen Entscheidungsprozess zur Verbesserung der Lastsituation durch.
Migrationsstrategien sind in sich geschlossene Systeme, die über Stunden,
Tage, Wochen oder Jahre arbeiten und Maßnahmen zum Erhalt oder Herstellen
von Lastausgleich vornehmen.
Für das Sammeln von Informationen bestimmen Migrationsstrategien sowohl
die Auslastung der auf den Rechnern vorhandenen CPUs als auch deren Speicherauslastung.
Nach der Bewertung der Informationen erfolgt der Entscheidungsprozess,
bei dem Maßnahmen zum Beheben von Unter- oder Überlast
13

KAPITEL 2 VERWANDTE ARBEITEN
getroffen werden. Während eines Entscheidungsprozesses müssen zuerst die
Objekte ausgewählt werden, deren Platzierung zum Beheben der Lastsituation
verändert werden müssen. Anschließend werden für die ausgewählten Objekte
die Rechner der neuen Platzierung bestimmt. Nach Abschluss des Entscheidungsprozesses
wird die Migration durchgeführt.
Für die Durchführung der Migration stellen die Migrationsstrategien verschiedene
Migrationsmechanismen bereit. Dies ist erforderlich, da Objekte, Prozesse
und Dateien unterschiedlich migriert werden müssen.
Eine weitere Aufgabe einer Migrationsstrategie ist die Informationsverteilung.
Bei der Informationsverteilung werden die gesammelten Lastinformationen
eines Rechners auf einen anderen Rechner übertragen. Erst durch die Informationsverteilung
hat eine Migrationsstrategie das globale Wissen über die
Lastsituation aller im Netzwerk befindlichen Rechnerknoten zur Verfügung
und kann Maßnahmen für eine wirkliche Balancierung der Rechnenlast treffen.
Migrationsstrategien in Lastverwaltungssystemen mit Lastbalancierung haben
auch die Aufgabe, die Initialplatzierung für Objekte durchzuführen. Für diese
Entscheidung sind globale Informationen der aktuellen Lastsituation aller
Rechner im Netzwerk von Vorteil.
Bei den Untersuchungen im Rahmen des Projekts DIOMEDES wurden die
Aufgaben von Migrationsstrategien in ein Komponentenmodell eingeordnet.
Hierbei entstand das in Abbildung 2.5 dargestellte Modell.
Abbildung 2.5: Komponentenmodell für Migrationsstrategien
Bei einigen Strategien war die Realisierung der Aufgaben jedoch so stark
miteinander verflochten, dass verschiedene Modelle entstanden. So fassen
MILOJIÈIÉ, PJEVAÈ und VALAÐEVIÆ in [MPV1991] in ihrer
Entscheidungsstrategie-Komponente die Aufgaben der Transferentscheidungs-
Komponente und der Lokalisierungs-Komponente von VEHMEIER [Veh1992]
14
Lastinformation der
Rechner im Netzwerk
sammeln
Lastsituation bewerten
und entscheiden, wie sie
verbessert werden kann
Transfer der neu zu
platzierenden Objekte
Entscheidungs-Komponente
an die veränderte
Lastsituation anpassen
Informationserfassung
Informationsverteilung
Entscheidung
Objektauswahl
Ortswahl
Transfer
Adaption
Lastinformation der
Rechner im Netzwerk
verteilen
Initialplatzierung
Auswahl der Objekte, die zur
Verbesserung der Lastsituation
neu platziert werden müssen
Auswahl der Rechner auf
denen ein neu zu platzierendes
Objekte platziert werden soll

2.2 MIGRATIONSTRATEGIEN
zusammen. GERNS und LIE teilen die Transferentscheidungs-Komponente von
VEHMEIER [Veh1992] jedoch in eine Entscheidungs-Komponente und eine
Objektauswahl-Komponente auf (siehe Abbildung 2.6).
Informationsstrategie
Entscheidungsstrategie
Transfermechanismus
Informationserfassung
Informationsverteilung
Entscheidung
Objektauswahl
Ortswahl
Transfer
Adaption
Abbildung 2.6: Modelle verschiedener Migrationsstrategien
Die Migrationsstrategie von GERNS und LIE enthält gegenüber den anderen
Modellen auch eine sogenannte adaptive Komponente. Sie hat die Aufgabe,
das Entscheidungsverhalten von Migrationsstrategien zur Laufzeit der veränderten
Lastsituation anzupassen. Eine solche adaptive Migrationsstrategie
wird im Abschnitt 2.3.4 näher vorgestellt.
2.3.4 ADAPTIVE OBJEKTMIGRATION MIT NEURONALEN NETZEN
Informationsgewinnung
Transferentscheidung
Lokalisierung
Transfer
[MPV1991] [GL1994] [Veh1992]
In dem Projekt DIOMEDES (siehe auch Abschnitt 2.3.3) [GL1994] wurde ein
System zur Untersuchung von Migrationsstrategien für verteilte Systeme
entwickelt. Im Rahmen dieses Projektes beschäftigten sich DENECKE und
WAHLBUHL mit der Entwicklung einer adaptiven Migrationsstrategie [DW1994].
Diese Strategie ermöglicht es, Parameter des jeweilig genutzten Migrations-
Verfahrens, wie beispielsweise Schwellwerte und Intervalllängen, aufgrund
langfristiger Beobachtungen an die jeweilige Lastsituation anzupassen.
Da Neuronale Netze auf Grundlage unvollständiger Informationen erfolgreich
arbeiten und zur Steuerung komplexer Systeme geeignet sind, bieten sie sich
zur Verarbeitung der gesammelten Daten an. Aus diesem Grund setzen
DENECKE und WAHLBUHL Neuronale Netze ein, um auf Grundlage ihrer Berechnungen
sowohl die Objektmigrationsverfahren, als auch die Einstellung der
Parameter der Migrationsverfahren vorzunehmen.
Objektmigrationsverfahren stellen für ein verteiltes System durch ihren Verbrauch
von Rechenkapazitäten und wegen der anfallenden Kosten für Kommunikation
eine zusätzliche Belastung dar. Die verursachten Kosten stehen
jedoch der Zielsetzung von Objektmigrationsverfahren – der Leistungssteigerung
– entgegen [DW1994]. Durch Verwendung von dynamischer Lastverteilung
hängt die Migrationsentscheidung vom aktuellen Systemzustand ab.
Außerdem mindern die bei der Migration entstehenden Kosten die durch
15

KAPITEL 2 VERWANDTE ARBEITEN
Migration erzielten Leistungsverbesserungen. Jedoch hängt die Wahl der
besten Lastverteilungsstrategie immer von dem aktuellen Systemverhalten ab.
Aus diesem Grund ist es sinnvoll, bei geringer Last eine andere Strategie zu
verfolgen als bei einer hohen Systemlast. Dies ist die Aufgabe der adaptiven
Komponente, um die Kosten zu minimieren und die Leistung zu steigern.
Wie oben erwähnt, erfolgt die Adaption durch Änderung der Parameter der
aktuellen Lastverteilungsstrategie. Die wichtigsten Parameter sind hierbei:
die Aufrufintervalle
zur Ermittlung der lokalen Last in periodischen Abständen,
zur Informationsverteilung an allen Rechnerknoten, bei regelmäßigen Nachrichtenaustausch
und
zur Entscheidung in periodischen Abständen, ob eine Über- oder Unterlast
vorliegt, sowie
die Schwellwerte
zur Entstehung der Initiierung einer Migrationsentscheidung, zur Ortsauswahl
und zum Bestimmen der minimalen Differenz zwischen lokaler Last
und der des entfernten Rechnerknotens, und die
Anzahl der Rechnerknoten für den Informationsaustausch.
Bei ersten Simulationen, die wegen ihres hohen Speicherverbrauchs nur 30
Minuten dauerten, hat sich gezeigt, dass bei hoher Speicherlast sich die Leistung
des Systems aufgrund der zusätzlichen Kosten verringert. Aus diesem
Grund ist es ratsam, die Intervalllängen für die periodische Informationsgewinnung,
bei hoher Systemlast, zu erhöhen. Außerdem schlagen DENECKE und
WAHLBUHL vor, bei Schwellwert-gesteuerten Entscheidungsstrategien den Parameter,
welcher das Vorliegen einer Überlast angibt, zu erhöhen. Mit diesen
Maßnahmen ist eine Minimierung der Kosten im Lastverteilungsverfahren zu
erreichen. Eine detaillierte Beschreibung der Leistungsmessungen der adaptiven
Migrationsstrategie kann in [DW1994] nachgelesen werden.
Adaptive Migrationsstrategien sind in dieser Diplomarbeit jedoch nicht
Gegenstand der Untersuchung. Zum Einen ist es nicht sinnvoll, in den zu
entwickelnden Migrationsstrategien Neuronale Netze einzusetzen, da diese
sich nur für die Beobachtung und Steuerung von Anwendung eignen, die über
einen längeren Zeitraum (z.B. > 5 Min) laufen. Zum Anderen sind die Berechnungen
zur Adaption von Strategien sehr Speicheraufwändig [DW1994], so
dass deren Einsatz zur Auslagerung von Speicherinhalten auf die Festplatte
führen könnte. Eine Auslagerung von Speicherinhalten ist jedoch mit einem
Abfall der Ausführungsgeschwindigkeit verbunden, die jedoch durch Migration
und Replikation gerade verbessert werden soll.
Die gewonnenen Erkenntnisse über den Einsatz von Schwellwerten und Auf-
16

2.2 MIGRATIONSTRATEGIEN
rufintervallen sind jedoch bei der Entwicklung von Migrationsstrategien im
JScatter-System berücksichtigt worden.
2.3 Capture-time based Thread Serialization
In [BH2002] wird mit Capture-time based Thread Serialization (CTS) eine
JVM vorgestellt, mit der Thread-Migration ohne Verlust von Zustandsinformationen
des zu migrierenden Threads möglich ist.
Die Migration von Threads ist ohne Verlust von Zustandsinformationen nur
durch eine JVM möglich, über die der Zustand des zu migrierenden Threads
ermittelt werden kann. Die Standard-JVM enthält keine solche Schnittstelle.
Aus diesem Grund ist mit ihr keine verlustfreie Thread-Migration möglich.
Die Werte der Variablen eines Threads werden innerhalb der Standard-JVM
auf einem Stack gespeichert, auf den von außerhalb nicht zugegriffen werden
kann. Da für Threads keine Migration in eine andere JVM vorgesehen ist,
enthält der Stack auch keine Typinformationen über die auf ihm platzierten
Daten. Die einzige Stelle an der die Typinformationen vorliegen ist der
Bytecode der Methoden, die die Daten auf den Stack legen.
Die einfachste Vorgehensweise, um an die Typinformationen zu gelangen ist,
den Java-Interpreter für jede Bytecodeinstruktion zu verändern und die
Typinformationen zu speichern, wenn sie auf den Stack gelegt werden. Der
größte Nachteil bei dieser Vorgehensweise ist jedoch, dass die JVM geändert
werden müsste, und durch das Speichern der Typinformationen ein großer
Overhead entstände. Aus diesem Grund schlägt CTS einen anderen Weg ein
und analysiert den Bytecode der Anwendung zur Migrationszeit, um an die
Typinformationen zu gelangen.
BOUCHENAK und HAGIMONT heben in [BH2002] hervor, dass Systeme, die
Thread-Migration auf Anwendungsebene durchführen, neben dem Informationsverlust
des Threadzustandes auch einen enormen Overhead an Quellcode
aufzuweisen. Jedoch gestehen sie ein, dass der Austausch der Standard-JVM
durch die CTS-JVM ein Nachteil ihres Ansatzes ist. Ein ausführlicher
Vergleich der beiden Ansätze wird in [BH2002] durchgeführt.
17

KAPITEL 2 VERWANDTE ARBEITEN
18

3 VORÜBERLEGUNGEN
3 VORÜBERLEGUNGEN
Nachdem im Kapitel 2 einige verwandte Arbeiten vorgestellt wurden, werden
in diesem Kapitel einige Überlegungen durchgeführt, die im Zusammenhang
mit Migrationsstrategien und deren Realisierung benötigt werden.
3.1 Migration und Replikation
Objektmigrationsstrategien beschäftigen sich damit, für eine gegebene Objektkonstellation
bei der verteilten Ausführung einer Anwendung die Platzierung
der Objekte so anzupassen, dass die Anwendung möglichst effizient ausgeführt
werden kann. Ergibt sich beim Überprüfen der Platzierung eines Objektes, dass
eine Änderung der Platzierung die Effizienz der Anwendung verbessern
könnte, wird der Umzug des Objektes durch Migration durchgeführt.
Wie aus diesen einleitenden Sätzen hervorgeht, sind Objekte der Untersuchungsgegenstand
von Migrationsstrategien. Aus diesem Grund beschäftigt
sich dieser Abschnitt im Folgenden mit Objekten sowie deren Migration bzw.
Replikation.
Beim Ausführen einer Anwendung werden Objekte im physikalischen Speicher
eines Rechners platziert. Damit Objekte unterschieden werden können,
besitzt jedes Objekt eine eindeutige Identität. Objekte haben Eigenschaften, die
in ihren Attributen (auch Felder genannt) gespeichert sind. Die Attribute
beschreiben den Zustand eines Objektes. Neben Eigenschaften besitzen
Objekte auch noch Operationen, die auch als Methoden bezeichnet werden.
Über die Operationen eines Objektes kann dessen Zustand entweder zugegriffen
oder aber verändert werden. Objekte stehen über Referenzen mit
anderen Objekten in Verbindung.
Bei der Migration eines Objektes wird es aus dem physikalischen Speicher
eines Rechners entfernt und in dem eines anderen Rechners neu platziert. Eine
Sonderform der Migration ist die Replikation. Bei ihr wird im Gegensatz zur
Migration eine Kopie des Objektes im selben physikalischen Speicher erstellt
und anschließend die Kopie in den eines anderen Rechners migriert. Kopien
eines Objektes werden auch als Replikate bezeichnet. Alle Replikate und das
Original-Objekt bilden eine Replikatgruppe. Die Objekte einer Replikatgruppe
haben identische Eigenschaften aber unterschiedliche Identität. Wird
der Zustand eines Objektes einer Replikatgruppe verändert, befinden sich die
Objekte der Replikatgruppe in einem unterschiedlichen oder inkonsistenten
Zustand. Da Replikatgruppen-Objekte die gleichen Eigenschaften haben, muss
die Zustandsänderung an alle Mitglieder der Replikatgruppe weitergegeben
werden.
Die Migration wie auch die Replikation eines Objektes kann nicht zu jedem
Zeitpunkt während der Programmausführung durchgeführt werden. Wenn ein
Objekt migriert werden soll kann es vorkommen, dass zu diesem Zeitpunkt
gerade eine oder mehrere Methoden des Objektes abgearbeitet werden. Damit
19

KAPITEL 3 VORÜBERLEGUNGEN
es bei der Durchführung der Migration nicht zu einem Fehler bei der
Ausführung der Methode kommt, muss vor dem Umzug des Objektes solange
gewartet werden, bis alle Methoden des Objektes abgearbeitet sind. Um diese
für die Durchführung einer Migration notwendige Situation herzustellen,
müssen alle Methodenaufrufe, die nach der Migrationsentscheidung auf das
Objekt ausgeführt werden sollen solange warten, bis die Migration durchgeführt
wurde. Anschließend sind die wartenden Methodenaufrufe zur neuen
Platzierung des Objektes weiterzuleiten und auf dem migrierten Objekt
auszuführen.
Diese Situation wird in [Lin2002] als sicherer Zustand für die Durchführung
einer Objektmigration bezeichnet. Dieser sichere Zustand muss analog auch
vor dem Durchführen einer Objektreplikation erreicht werden. Den Zeitpunkt
in dem sich ein Objekt in einem für seine Migration sicheren Zustand befindet
bezeichnet LUX [Lux1995] als Migrationspunkt.
Damit ein Objekt migriert werden kann, muss von dem Zustand des Objektes
ein transportierbares Abbild erzeugt werden können, aus dem nach der
Übertragung wieder ein Objekt mit identischem Zustand rekonstruiert werden
kann. Dieser Vorgang wird Objektserialisierung genannt und im Abschnitt
3.2 näher untersucht. Somit ist die Objektserialisierung eine notwendige
Bedingung für die Migrierbarkeit bzw. Replizierbarkeit eines Objektes. Durch
statische Programmanalysen können weitere Aussagen über die Migrierbarkeit
bzw. Replizierbarkeit eines Objektes gemacht werden. Hiermit beschäftigt sich
Abschnitt 3.4.
3.2 Objektserialisierung
In Abschnitt 3.1 wurde herausgearbeitet, dass Objektserialisierung eine Grundvoraussetzung
für das Durchführen von Migration und Replikation ist. Bei
Objektserialisierung handelt es sich um das Erstellen eines transportierbaren
Abbildes eines Objektes, aus dem durch Deserialisierung ein Objekt mit identischem
Zustand rekonstruiert werden kann. In diesem Abschnitt wird das
Konzept Objektserialisierung vorgestellt und am Beispiel der JDK-Serialisierung
dessen Vorgehensweise im JDK (Java Development Kit) erläutert.
Der Zustand eines Objektes lässt sich in zwei Teile untergliedern. Zum
sogenannten persistenten Zustand gehören alle Objektbestandteile, die auch
nach der Deserialisierung des Objektes verfügbar sind. Alle anderen Objektbestandteile
gehören zum nicht-persistenten Zustand eines Objektes. In einigen
Programmiersprachen, z. B. Java, können Felder, die nur lokale Ressourcen
wie Dateien oder temporale Werte enthalten, als transient gekennzeichnet
werden. Sie bilden nur vorübergehend einen Teil des Objektzustandes oder
können rekonstruiert werden und gehören deshalb zum nicht-persistenten
Zustand eines Objektes. Somit kann an dieser Stelle festgehalten werden, dass
Objektserialisierung das Speichern des persistenten Zustands eines Objektes
ist.
20

3.2 OBJEKTSERIALISIERUNG
Bei der JDK-Serialisierung wird der Zustand des Objektes in einen byte-
Strom serialisiert, aus dem durch Deserialisierung eine Kopie des Objektes im
selben Zustand rekonstruiert werden kann. Mit der JDK-Serialisierung können
jedoch nur Objekte serialisiert werden, die Java's Serialisierungs-Schnittstelle
erfüllen. Hierfür muss jede Klasse eines Java-Objektes oder eine seiner
Oberklassen das Interface Serializable oder dessen Subinterface
Externalizable implementieren. Diese Objekte werden als serialisierbare
Objekte bezeichnet.
Bei der Standard-JDK-Serialisierung werden alle Felder eines Objektes in
einen byte-Strom geschrieben, die in ihrer Klasse nicht als transient oder
static gekennzeichnet sind. Enthält ein Feld ein Objekt muss es serialisierbar
sein. Felder, die primitive Datentypen enthalten sind immer serialisierbar.
Wenn das Objekt eines Feldes serialisiert wird, werden alle seine Felder
serialisiert. Auf diese Weise wird der gesamte Objektgraph, der direkt oder
indirekt mit einem zu serialisierenden Objekt verbunden ist mit serialisiert
[Sun2001]. Sind bei der Serialisierung des Objektgraphen zyklische Strukturen
durch mehrfache Referenzierung auf dasselbe Objekt enthalten, werden diese
durch eine Hashtabelle aufgelöst [NPH1999]. Handelt es sich bei dem zu
serialisierenden Objekt um einen Arraytyp, wird die Anzahl seiner Elemente
und die Elemente analog wie bei Objekten bzw. primitiven Datentypen
beschrieben serialisiert.
Byte-Strom
Byte-Strom
serialisierte
Daten
Objekt
Objekt (Kopie)
Legende
persistenter Zustand
nicht-persistenter Zustand
Abbildung 3.1: Serialisierung und Deserialisierung eines Objektes im JDK
Bei der Deserialisierung des Zustandes eines Objektes werden alle Felder mit
ihrem typ-spezifischen Initialwert initialisiert. Anschließend werden allen
Feldern, die zum persistenten Zustand des Objektes gehören, die serialisierten
Werte zugeordnet. In Abbildung 3.1 ist die Serialisierung und Deserialisierung
zusammenfassend visualisiert.
Es gibt jedoch auch Klassen, deren Objekte nicht serialisiert werden können.
Ein Beispiel hierfür ist die Klasse Object, die die Wurzel aller Klassen bildet.
Somit gibt es in der Klassenhierachie eines zu serialisierenden Objektes immer
eine Oberklasse, dessen Objekte nicht serialisierbar sind. Da alle Klassen über
21

KAPITEL 3 VORÜBERLEGUNGEN
Konstruktoren und vererbte Klassenteile mit ihren Oberklassen verbunden
sind, müssen diese Klassenbestandteile mit serialisiert werden. Damit Klassen
mit nicht-serialisierbaren Oberklassen trotzdem serialisiert werden können,
müssen ihre nicht-serialisierbaren Oberklassen einen accessible Konstruktor
ohne Parameter besitzen. Das heißt, die Klasse muss einen Konstruktor
definieren, der als public deklariert ist und keine Parameter enthält. Hierbei
ist jedoch der Standard-Konstruktor nicht ausreichend, er muss konkret in der
nicht-serialisierbaren Klasse definiert werden [GJS1996].
Die accessible Konstruktoren ohne Parameter werden für die Deserialisierung
eines Objektzustandes benötigt. Sie werden bei der Deserialisierung als erstes
aufgerufen, anschließend werden die weiteren Bestandteile des Objektes
deserialisiert.
In verteilten Anwendungen wird Objektserialisierung sehr oft durchgeführt.
Deshalb bietet eine nicht-effiziente Objektserialisierung ein großes Einsparpotential
für die effiziente Ausführung einer verteilten Anwendung. PHILIPPSEN
und HAUMACHER haben sich mit der Verbesserung der JDK-Serialisierung
befasst und eine effizientere Objektserialisierung namens UKA-Serialisierung
[PH1999] entwickelt. Sie baut auf der JDK-Serialisierung auf, ist jedoch 20% -
50% schneller als die JDK-Serialisierung. Wie der Geschwindigkeitsvorteil
erreicht wurde, kann in [PH1999] nachgelesen werden. In ihrer grundlegenden
Vorgehensweise unterscheiden sich JDK-Serialisierung und UKA-Serialisierung
nicht.
3.3 Parameter von Migrationsstrategien
Einige Migrationsstrategien besitzen Parameter, die den Entscheidungsprozess
über Migration, Replikation oder die Beibehaltung der Platzierung eines
Objektes beeinflussen. Diese Parameter stellen meist Schwellwerte dar die
darüber Auskunft geben, ab oder bis zu welcher Anzahl von Zugriffen ein
Objekt migriert oder repliziert wird.
Wie entscheidend die Wahl des Schwellwertes für Migration das Verhalten
eines verteilten Systems beeinflusst, wurde in [DW1994] hervorgehoben. Eine
zu niedrige Wahl des Schwellwertes führt zu hoher zusätzlicher Belastung des
verteilten Systems. Im Gegensatz dazu verhindert eine zu hohe Wahl des
Schwellwertes die Leistungsverbesserung, die durch Migration und Replikation
erreicht werden soll.
Im Abschnitt 2.2.2 wurde schon darauf eingegangen, dass einige Migrationsstrategien
einen Replikationslevel besitzen, der die Höchstgrenze der im
verteilten System befindlichen Replikate eines Objektes angibt. Findet auf ein
Replikat ein Schreibzugriff statt, bestimmt der Replikationslevel und die
hierdurch verursachte Größe der Zustandsänderung, wie hoch der Aufwand für
den Datentransfer ist, um alle Replikate des Objektes im verteilten System
konsistent zu halten.
22

3.3 PARAMETER VON MIGRATIONSSTRATEGIEN
Dieser Effekt macht deutlich, dass durch den Einsatz von Replikation nicht nur
schnelle Zugriffe durch lokale Kopien von Objekten erreicht werden, sondern
auch Leistungsverlust durch Aktualisieren der verteilten Replikate entsteht.
Auch bei der Migration tritt ein ähnlicher Effekt auf. Wenn eine Migrationsstrategie
entschieden hat ein Objekt zu migrieren, werden alle ehemals lokalen
Zugriffe durch die Migration zu entfernten Zugriffen. Hierbei kann es
vorkommen, dass nach der Migration die ehemals lokal zugreifenden Objekte
mehr Datenverkehr verursachen als das ehemals entfernt zugreifende Objekt
verursacht hat. Dieser Effekt muss beim Entwerfen einer Migrationsstrategie
verhindert werden. Hierfür ist nicht nur auf die Wahl des Schwellwertes
sondern auch auf dessen Einsatz in der Migrationsstrategie zu achten.
Das Einstellen der optimalen Parameter für eine Migrationsstrategie ist eine
schwierige Aufgabe. In [DW1994, Rei1997] wird hervorgehoben, dass die
optimalen Parameter einer Migrationsstrategie erst nach mehrmaligem
Ausführen für eine konkrete Anwendung ermittelt wurde. Demnach ist es nicht
möglich, die Schwellwerte einer Migrationsstrategie so zu wählen, dass sie
einmal eingestellt, für alle verteilt auszuführenden Anwendungen gleich gute
Ergebnisse liefern, sondern individuell für jede Anwendung bestimmt werden
müssen.
3.4 Statische Programmanalyse
Durch statische Programmanalyse können zum Einen schon vor der Ausführung
einer Anwendung Aussagen über das Verhalten der Anwendung
gemacht werden. Zum Anderen kann die Anwendung oder Teile der Anwendung
auf spezielle Eigenschaften untersucht werden.
In Zusammenhang mit Migrationsstrategien ist es deshalb möglich, vor der
Ausführung, die Klassen einer Anwendung auf spezielle Eigenschaften zu
untersuchen um festzustellen, ob die Instanzen der Klasse zur Laufzeit
repliziert werden sollen, oder eine Migration der Replikation vorzuziehen ist.
Eine Replikation sollte einer Migration vorgezogen werden, weil nach der
Replikation alle Objekte der verteilten Anwendung lokal auf das replizierte
Objekt zugreifen können jedoch durch Migration nur einige. Lokale Zugriffe
auf ein Objekt sind mit weniger Datenverkehr verbunden als entfernte Zugriffe
und steigern somit die Effizienz des Programms.
Für diese Untersuchungen bieten sich die Immutable-Feldanalyse und die
Immutable-Objektanalyse an.
Mit der Immutable-Feldanalyse [Thi2001] kann bestimmt werden, ob die
Felder einer Klasse nicht modifiziert werden und somit konstant sind. Objekte
von Klassen, die während der gesamten Ausführung eines Programms nicht
verändert werden bieten sich für die Replikation an.
Mit der Immutable-Objektanalyse kann für eine gesamte Anwendung
untersucht werden, ob die Instanz einer Klasse modifiziert wird. Hierfür setzt
23

KAPITEL 3 VORÜBERLEGUNGEN
die Immutable-Objektanalyse die Immutable-Feldanalyse und die globale Def-
Use-Analyse ein.
Mit der globalen Def-Use-Analyse werden alle Verwendungsstellen eines
Feldes in der gesamten Anwendung gefunden. Verwendungsstellen eines
Feldes sind alle Stellen einer Anwendung, an denen auf das Feld lesend oder
schreibend zugegriffen wird. Die Erzeugungsstelle eines Feldes ist die Stelle
einer Anwendung, an der das Feld vor der Initialisierung definiert wird.
Die globale Def-Use-Analyse beginnt bei der Erzeugungsstelle des Feldes und
ermittelt über die Methodenaufrufe auf das zu untersuchende Feld alle
Verwendungsstellen des Feldes. Die Abbildung 3.2 zeigt ein Beispiel für das
Finden aller Verwendungstellen eines Feldes mit Hilfe der globalen Def-Use-
Analyse.
5
10
15
20
class A {
}
int i;
B b;
A() {
i = 5;
b = new B(i);
}
getB() { return b; }
class B {
}
int value;
B(int i) { value = i; }
getValue() { return value; }
setVale(int i) { value = i; }
25
30
35
40
45
class C {
}
A a;
B b1;
C() {
a = new A();
b1 = a.getB();
}
m(boolean value, int i) {
int x = 0;
}
Legende
if(value)
x = b1.getValue();
else
b1.setValue(i);
...
Erzeugungsstelle
Verwendungsstelle (Schreibzugriff)
Verwendungsstelle (Lesezugriff)
Abbildung 3.2: Beispiel einer Def-Use-Analyse für Feld b der Klasse A
Im Beispiel sind die Klassen A, B und C gegeben. Die Klasse C enthält ein Feld
a vom Typ A und ein Feld b1 vom Typ B, die über den Konstruktor von C
initialisiert werden. Des Weiteren enthält Klasse C eine Methode m. Die Klasse
A enthält ein Feld i vom Typ int und ein Feld b vom Typ B sowie eine
Methode getB über die auf b zugegriffen werden kann. Die Klasse B enthält
ein Feld value vom Typ int und jeweils eine Methode über die lesend oder
schreiben auf das Feld zugegriffen werden kann.
Nun sollen für das Feld b der Klasse A alle Verwendungsstellen bestimmt
werden. Die Def-Use-Analyse beginnt an der Erzeugungsstelle von b in der
Klasse A. Anschließend sucht sie nach allen Stellen im Programm, an denen
die Methode getB auf ein A-Objekt aufgerufen wird. Eine solche Stelle
befindet sich im Konstruktor der Klasse C. An dieser Stelle wir dem Feld b1 die
Speicherstelle von b zugewiesen. Nach dieser Zuweisung sind alle Verwendungsstellen
von b1 auch potentielle Verwendungsstellen von b. Aus diesem
24

3.4 STATISCHE PROGRAMMANALYSE
Grund sucht die Def-Use-Analyse auch nach allen Verwendungsstellen von b1
und findet sie in der Methode m der Klasse C. In der Methode m wird über die
Fälle einer if-Anweisung einmal lesend und einmal schreibend auf b1
zugegriffen. In der Immutable-Objektanalyse werden Stellen, die wie eine if-
Anweisung von der Auswertung der Anweisung abhängen, konservativ
abgeschätzt und somit als Schreibzugriffe interpretiert.
In [Rei1997] wurde durch dynamische Analyse festgestellt, dass Objekte, bei
denen höchstens 10% aller Zugriffe Schreibzugriffe sind sich besonders gut für
Replikation eignen. Ist die Anzahl der Schreibzugriffe höher, wird der positive
Effekt von lokalen Zugriffe verringert.
Damit nicht unnötig auf Replikation verzichtet wird, weil die Anzahl der
Verwendungsstellen mit Schreibzugriff sehr hoch ist, muss überprüft werden,
in welchem Teil des Programms die Schreibzugriffe erfolgen. Finden die
meisten Zugriffe bei der Initialisierung des Objektes statt, kann das Objekt
trotzdem repliziert werden, wenn der Anteil alle weiteren Schreibzugriffe
höchstens z. B. 10% beträgt.
In Abschnitt 3.2 wurde herausgearbeitet, dass Thread-Migration nur durch eine
erweiterte JVM ohne Verlust von Informationen möglich ist. Deshalb sollten
aktive Objekte nicht auf Anwendungsebene migriert werden. In Java gibt es
zwei Möglichkeiten um aktive Objekte zu erzeugen. Zum Einen durch
Erweitern der Klasse Thread und zum Anderen durch Implementieren des
Interfaces Runnable.
Durch Klassenhierachieanalyse können die Oberklassen einer Klasse ermittelt
werden. Wird durch Klassenhierachieanalyse festgestellt, dass eine Klasse eine
Unterklasse von Thread ist oder Runnable implementiert, werden die
Instanzen der Klasse zur Laufzeit weder migriert noch repliziert.
Statische Programmanalysen sich sehr aufwändig. Deshalb sollten sie nicht
während der Laufzeit, sondern vor der Ausführung des Programms durchgeführt
werden, um die Effizienz der verteilt ausgeführten Anwendung nicht zu
beeinträchtigen [TK1998 , Thi1999].
3.5 Dynamische Programmanalyse
Die dynamische Programmanalyse dient zum Beobachten des Verhaltens einer
Anwendung zur Laufzeit. Hierbei werden Zählvariablen eingesetzt über die
ermittelt werden kann, wie oft auf ein Objekt von einem anderen Objekt aus
zugegriffen wurde. Einige Systeme, wie beispielsweise Juggle [SH1998] halten
noch zusätzliche Zählvariablen. Zum Einen unterscheiden sie zwischen Leseund
Schreibzugriffen und zum Anderen zwischen entfernten und lokalen
Zugriffen auf ein Objekt.
Neben dem Zählen der Ausführungshäufigkeit von Programmstellen wird
dynamische Programmanalyse auch eingesetzt, um die Auslastung der CPU,
die Verteilung von CPU-Zeiten bei der Nutzung verschiedener Programmteile
25

KAPITEL 3 VORÜBERLEGUNGEN
oder den Nutzungsgrad eines Caches zu bestimmen [RP1999].
Die Auslastung der CPU wird in verteilten Betriebssystemen, wie Birlix
[Lux1995] und Lastverwaltungssystemen [Lin2002] in Migrationsstrategien
bei der Migrationsentscheidung eingesetzt. In Lastverwaltungssystemen werden
jedoch auch die Auslastung des Hauptspeicher und der Plattenkapazität bei
der Migrationsentscheidung betrachtet.
Um die Information über die Belegung der Ressourcen eines Rechners im
verteilten System präsent zu haben, werden sie beispielsweise über Broadcast
verteilt [DW1994].
Da die dynamische Programmanalyse zur Laufzeit ausgeführt wird, beeinträchtigt
sie die effektive Ausführung einer verteilten Anwendung. Damit die
Beeinträchtigung so gering wie möglich ist, werden Zählvariablen erst dann
erzeugt, wenn sie benötigt werden. Juggle [SH1998] führt aus diesem Grund
die Instrumentierung der verteilt ausgeführten Anwendung erst dann durch,
wenn die Daten notwendig sind. Auf diese Weise wird nicht nur Laufzeit
sondern auch Speicher gespart.
26

4 DAS JSCATTER-SYSTEM
4 DAS JSCATTER-SYSTEM
In diesem Kapitel wird das JScatter-System [FFF+2002] vorgestellt, in dem die
Realisierung des entwickelten Modells für Migrationsstrategien durchgeführt
wurde. Ziel dieses Kapitels ist es, einen grundlegenden Überblick über die
Struktur des Systems zu vermitteln und einen Einblick in den Aufbau und die
Vorgehensweise der Teilkomponenten des Systems zu geben.
Mit dem JScatter-System 1 ist es möglich, eine nebenläufige Java-Anwendung
transparent für den Benutzer so zu transformieren, dass sie unter Verwendung
mehrerer Rechner in der JScatter-Laufzeitumgebung verteilt ausgeführt werden
kann.
Für die Transformation besitzt das System einen Transformator, der in Abschnitt
4.2 näher beschrieben wird. Der Transformator benötigt als Eingabe
den Bytecode der zu transformierenden Anwendung inklusive aller verwendeten
Bibliotheken, die nicht zur Java-Standard-Bibliothek gehören. Zur Ausführung
des transformierten Programms enthält das JScatter-System eine eigene
Laufzeitumgebung, auf die im Abschnitt 4.3 näher eingegangen wird.
Für die Initialplatzierung der einzelnen Objekte dient ein eigens hierfür von
KARSTEN KLOHS [Klo2002] entwickelter Verteilungsplan, der auf statischer
Programmanalyse beruht und im Abschnitt 4.4 vorgestellt wird.
vor der Laufzeit
zur Laufzeit
Java-Virtual-
Machine
Java-Virtual-
Machine
Rechnerknoten
Rechnerknoten
Verteilungsplan
Verteilungsplan
Java-Anwendung
(Bytecode)
Transformator Verteilungsplan
Laufzeitumgebung
Java-Virtual-
Machine
Java-Virtual-
Machine
Rechnerknoten
Rechnerknoten
Verteilungsplan
Verteilungsplan
Abbildung 4.1: Die Struktur des JScatter-Systems [FFF+2002]
In Abbildung 4.1 ist die grobe Struktur von JScatter und das Zusammenspiel
seiner Teilkomponenten dargestellt.
1 JScatter wurde ursprünglich unter dem Namen ParJava [FFF+2002] entwickelt.
27

KAPITEL 4 DAS JSCATTER-SYSTEM
Damit die transformierte Anwendung in der verteilten Laufzeitumgebung genauso
ausgeführt werden kann, wie die Originalanwendung in einer zentralen
JVM, war es notwendig, jede Klasse der Originalanwendung so zu zerlegen,
dass die Semantik der Ergebnisklassen in der verteilten Laufzeitumgebung der
Semantik einer Originalklasse entsprechen. Hierfür wurde ein Transformationskonzept
entwickelt das sicherstellt, dass der Klassenanteil einer Originalklasse
in der verteilten Laufzeitumgebung nur einmal vorhanden ist, der
Instanzenanteil jedoch mehrfach auf jedem Rechner vorhanden sein und von
entfernten Rechnern aus eindeutig identifiziert und zugegriffen werden kann.
Das Transformationskonzept, welches sowohl die Vorgehensweise des Transformators
als auch die Struktur der Laufzeitumgebung beeinflusst hat, wird im
anschließenden Abschnitt 4.1 vorgestellt.
4.1 Transformation einer Java-Klasse
Die Transformation einer Java-Klasse, zu ihrer Repräsentation in einer verteilten
Laufzeitumgebung, ist eine nicht triviale Aufgabe. Das im JScatter-System
verwendete Konzept basiert auf dem Transformationskonzept einer Java-
Klasse des JavaParty-Systems (siehe Abschnitt 2.1). Im Unterschied zu Java-
Party zerlegt es eine Java-Klasse jedoch nicht in sechs Klassen und sieben
Interfaces sondern nur in vier Klassen und zwei Interfaces (siehe Abbildung
4.2), deren Aufgaben nun im Einzelnen erläutert werden.
Abbildung 4.2: Klassenaufteilung einer Klasse Example
In Abbildung 4.2 sind die Ergebnisklassen der Transformation einer Klasse
namens Example dargestellt. Bei der Transformation einer Klasse entsteht
28
Example
(Originalklasse)
Example
(Instanzenanteil)
_ExampleHandel
(dient als Proxy und ermöglicht
den entfernten Zugriff auf ein
Example-Objekt)
_ExampleInstanceManager
(verwaltet alle Example-
Objekte auf einem
Rechnerknoten)
_ExampleClassObject
(Klassenanteil)
Legende
Klasse
Interface
Klasse zerlegt in ...
Klasse erweitert Klasse
Klasse implementiert Interface
_ExampleInstanceManagerInterface
(erfüllende RMI-Bedingung)
_ExampleClassObjectInterface
(erfüllende RMI-Bedingung)

4.1 TRANSFORMATION EINER JAVA-KLASSE
eine gleichnamige Klasse, die jedoch nur die Instanzenanteile der Originalklasse
enthält. Diese neue Klasse Example repräsentiert in der transformierten
Anwendung den Instanzenanteil der Originalklasse. Die Felder und Methoden,
die in der Originalklasse zum Klassenanteil gehören, bilden die Felder und Methoden
der Klasse _ExampleClassObject. Sie stellt in der transformierten
Anwendung den Klassenanteil der Originalklasse Example dar.
Im Unterschied zur Originalklasse sind die Felder und Methoden jedoch nicht
mehr statisch, sondern werden durch gleichnamige Instanzenfelder und
Instanzmethoden ersetzt. Diese Ersetzung des statischen durch Instanzenanteil
war notwendig, da statischer Klassenanteil in einer JVM nur einmal vorhanden
ist, die verteilte Laufzeitumgebung jedoch aus mehreren JVMs besteht, die auf
verschiedenen Rechnern verteilt platziert sind.
In der verteilten Laufzeitumgebung darf der Klassenanteil einer Klasse auch
nur einmal vorhanden sein, jedoch kann er in verschiedenen JVMs der verteilten
Laufzeitumgebung für Zugriffe benötigt werden. Aus diesem Grund
steht in allen JVMs ein Stellvertreter auf die Klassenanteil-repräsentierende
Instanz _ExampleClassObject zur Verfügung. Da die Kommunikation zwischen
Stellvertreter und Original über RMI durchgeführt wird, wird für die
Beispielklasse ein Interface namens _ExampleClassObjectInterface
generiert, das die entfernte Schnittstelle auf das _ExampleClassObject
definiert.
besitzt
1 ..*
besitzt
1
Object
Example
_ExampleHandel
InstanceManager
_ExampleInstanceManager
Serializable
Handle
_ExampleInstanceManagerInterface
Anmerkung: Um die Verbindungen der Klassen zu verdeutlichen,
wurden die Assoziationen zwischen _ExampleHandel und _Example-
InstanceManager und _ExampleInstanceManager und Example
zusätzlich eingezeichnet.
UnicastRemoteObject
Remote
_ExampleClassObjectInterface
Abbildung 4.3: Klassenhierachie der Klasse Example
ClassObject
Legende
X Y
X Y
n
X Y
_ExampleClassObject
So wie in der Originalanwendung mehrere Instanzen einer Klasse in einer JVM
erzeugt werden können, muss dies in einer verteilten Laufzeitumgebung
möglich sein. Aus diesem Grund wird für die Originalklasse eine Klasse mit
Klasse
Interface
X erweitert Y
X implementiert Y
X assoziiert n Y
29

KAPITEL 4 DAS JSCATTER-SYSTEM
Suffix InstanceManager generiert, die alle Instanzenanteil-repräsentierenden
Objekte der Originalklasse pro Rechner verwaltet. Somit ist zur Laufzeit
auf jeden beteiligten Rechner der verteilten Laufzeitumgebung genau eine
Verwaltungsinstanz pro Originalklasse vorhanden.
Damit auf ein entfernt platziertes Instanzenanteil-repräsentierendes Objekt
auch über seine Verwaltungsinstanz zugegriffen werden kann, wurde eine
Stellvertreterklasse mit Suffix Handle geschaffen, deren Instanzen zur
Laufzeit jeweils über eine Referenz zum zugehörigen InstanceManager
verfügen. Über diese Referenz leitet ein Handle zur Laufzeit Zugriffe auf das
Instanzenanteil-repräsentierende Objekt weiter.
Eine ausführliche Beschreibung des Klassentransformationskonzepts kann in
[FFF+2002] nachgelesen werden.
In der Abbildung 4.3 ist beispielhaft für die Klasse Example, die nach der
Transformation bestehende Klassenhierachie dargestellt. Hierbei ist im Zusammenhang
mit Abbildung 4.2 zu sehen, dass Klassen mit dem Suffix
Handle, InstanceManager und ClassObject gemäß ihren Suffixen
gleichnamige Klassen erweitern.
4.2 Transformator
Der Transformator erzeugt aus einer übersetzten Java-Anwendung, unter
Verwendung des in Abschnitt 4.1 erläuterten Transformationskonzeptes, eine
Java-Anwendung, die im JScatter-Laufzeitsystem verteilt ausgeführt werden
kann.
Für die Arbeit mit Java-Klassen setzt der Transformator die Bibliothek BCEL
[Dah1998, Dah2001] und die Analyseumgebung Pauli [Thi2001] ein. Bei der
Transformation einer Java-Anwendung werden Instruktionen zum Bytecode
der Klassen hinzugefügt, über die zur Laufzeit mit einem Verteilungsplan
(siehe Abschnitt 4.4) die Rechnerknoten bestimmt werden, auf denen ein
Objekt platziert wird.
Der Transformationsprozess besteht aus vier Phasen (siehe Abbildung 4.4). In
der ersten Phase, der Hüllenbildung, wird die Menge aller Klassen und
Methoden der Eingabeanwendung sowie der notwendigen Bibliotheken
inklusive der Java-Standard-Bibliothek auf den minimal zur Ausführung
benötigten Umfang reduziert [FFF+2002].
Die Hüllenbildung wird mit einem Werkzeug namens Jode [JSN2002] durchgeführt.
Jode benötigt als Eintrittspunkte die Namen der Methoden einer
Klassen, von denen aus die Anwendung ausgeführt wird.
In der zweiten Phase, der sogenannten Stellenersetzung, werden alle zu transformierenden
Stellen untersucht, an denen entweder ein neues Objekt erzeugt
wird (Erzeugungsstelle) oder ein erzeugtes Objekt verwendet wird (Verwendungsstelle).
In der dritten Phase generiert der Transformator alle Klassen,
30

nach dem in Abschnitt 4.1 beschriebenen Transformationskonzept.
Java-Anwendung
Class C
Class ................ B
................ ................
Class A
................
................
Abbildung 4.4: Grober Ablauf der Transformation
4.2 TRANSFORMATOR
Bei Verwendungstellen muss in der dritten Phase darauf geachtet werden, ob
es sich bei dem Zugriff um ein lokal oder entfernt platziertes Objekt handelt.
Eine Erzeugungsstelle wird in der dritten Phase mit speziellem Code angereichert,
durch den die Initialplatzierung des Objektes zur Laufzeit festgelegt
wird. In der den Transformationsprozess abschließenden vierten Phase, werden
alle für die RMI-Kommunikation benötigten Stub- und Skeletonklassen
erzeugt.
4.3 Laufzeitumgebung
Transformator
Phase 1: Hüllenbildung
Phase 2: Stellenersetzung
Phase 3: Klassen erzeugen
Java-Anwendung ausführbar in
JScatter-Laufzeitumgebung
Class C
Class A
Skeleton ................ Class B
................
................ ................ Terface ................
................ _CClassObject
................ ................ ................Stub
.............................. Manager
................ ................
..............................
................
................
..............................
................
Phase 4: Stubs und Skeletons erzeugen
Bibliotheken
Die Aufgabe der Laufzeitumgebung ist es, die transformierte Java-Anwendung
transparent für den Benutzer unter Verwendung aller beteiligten Rechner
verteilt auszuführen. Hierfür verbindet die Laufzeitumgebung, die auf den verschiedenen
Rechnern vorhandenen JVMs miteinander. Die JVMs werden zur
Laufzeit über die Instanzen der Klasse Node repräsentiert. Die Nodes kommunizieren
über RMI miteinander. Die zentrale Instanz der verteilten Laufzeitumgebung
stellt die Klasse RuntimeManger dar, an die zur Laufzeit alle
Fehlermeldungen der beteiligten JVMs sowie der ausgeführten Anwendung
weitergeleitet werden.
Damit von jeder an der verteilten Ausführung des transformierten Programmes
beteiligten JVM aus ein Objekt entfernt platziert werden kann, ist in jeder JVM
eine Instanz des Verteilungsplans (siehe Abschnitt 4.4) enthalten.
Neben dem Verbinden der beteiligten Rechner dient die Laufzeitumgebung
auch als Schnittstelle zum verteilt auszuführenden Programm. Hierfür enthält
Jode
Pauli
BCEL
Verteilungsplan
RMIC-Tool
31

KAPITEL 4 DAS JSCATTER-SYSTEM
sie eine Klasse RuntimeEnvironment, von der zur Laufzeit pro JVM genau
eine Instanz vorhanden ist. Diese Schnittstelle wird vom verteilt auszuführenden
Programm verwendet, um auf die Instanzen- und Klassenanteil-repräsentierenden
Objekten zuzugreifen. Hierbei können die Zugriffe sowohl lokal als
auch entfernt durchgeführt werden. Auf die Besonderheiten bei einem Zugriff
wurde schon im Abschnitt 4.2 eingegangen. Eine graphische Darstellung der
geschilderten Aufgaben und Vorgehensweisen der verteilten Laufzeitumgebung
stellt Abbildung 4.5 dar.
Abbildung 4.5: Vorgehensweise der Laufzeitumgebung mit zwei Rechnern
4.4 Verteilungsplan
Wie am Anfang des Kapitels beschrieben, bestimmt der Verteilungsplan
[Klo2002] auf Grundlage statischer Programmanalyse die Initialplatzierung der
Objekte der im JScatter-System verteilt auszuführenden Anwendung.
Bereits nach der Transformation der Anwendung (siehe Abschnitt 4.2) enthält
das transformierte Programm an allen Stellen, an denen ein Objekt initial
platziert wird, einen Aufruf an den lokalen Verteilungsplan. Das Ergebnis der
Anfrage bestimmt, ob das Objekt lokal oder entfernt platziert wird. Die Laufzeitumgebung
führt zur Laufzeit die Platzierung des Objektes durch. Die
Abbildung 4.6 stellt den Ablauf bei der Platzierung eines Objektes durch den
Verteilungsplan im JScatter-System dar.
In der aktuellen Version des Verteilungsplans stehen verschiedene Verteilungsstrategien
bereit, die nach belieben ausgetauscht werden können.
Der Verteilungsplan verfügt über eine Schnittstelle, über die bei Verteilungsstrategien
auch Ergebnisse aus dynamischer Programmanalyse (siehe Abschnitt
3.2.5) genutzt werden können. So kann eine Verteilungsstrategie, auf Grund-
32
Node
Rechner A
Klassenanteilrepräsentierende
Objekte
Instanzenanteilrepräsentierende
Objekte
Node_Stub
Node_Skeleton
RuntimeManager_Stub
RuntimeEnvironment
Verteilungsplan
Laufzeitumgebung
Instanzenanteilrepräsentierende
Objekte
Node_Skeleton
Node_Stub
Node_Stub
Klassenanteilrepräsentierende
Objekte
Rechner B
RuntimeManager
Node
Node_Stub
RuntimeManager_Skeleton
Verteilungsplan
RuntimeEnvironment
RuntimeManager_Stub

4.4 VERTEILUNGSPLAN
lage der schon im System platzierten Objekte, ein initial zu platzierendes
Objekt auf einem entfernten Rechnerknoten platzieren, um beispielsweise andere
Rechnerknoten von zusätzlichen Fernzugriffen zu entlasten [Klo2002].
vor der Laufzeit
während der Transformation
zur Laufzeit
Rechner 1
Verteilungsplan
Class A
................
................
................
RuntimeEnvironment
Node
Transformator
Class C
Class
................
B
................
Class ................ A
................ ................
................
................ ................
................
................
................
Laufzeitumgebung
Node
C
Verteilungsplan
Rechner 2
Verteilungsplan
RuntimeEnvironment
Class B
................
................
................
Legende
.............. Bytecode
Zusätzlicher Code für
Verteilungsplanaufruf
Referenz zwischen Objekten
im JScatter-Laufzeitsystem
Referenz zwischen Objekten
im JScatter-Laufzeitsystem
über RMI-Schnittstelle
Laufzeitsystem-Objekt
Objekt der parallele
ausführbaren Anwendung
im JScatter-System
Ablauf:
Beim Abarbeiten einer Methode von
Objekt A auf Rechner 1 bestimmt
der Verteilungsplan, ein Objekt C auf
Rechner 2 zu erzeugen. Über das
RuntimeEnvironment auf Rechner 1
und den Nodes auf Rechner 1 und 2
erzeugt die Laufzeitumgebung das
Objekt C auf Rechner 2.
Abbildung 4.6: Initialplatzierung eines Objektes durch den Verteilungsplan
Für statische Programmanalyse, die im Abschnitt 3.2 behandelt wurde, setzt
der Verteilungsplan die Analyseumgebung Pauli [Thi2001] ein. Mittels Pauli
kann eine große Anzahl statischer Programmanalysen durchgeführt werden,
auf die in Kapitel 6 eingegangen wird.
Für eine genauere Beschreibung des Verteilungsplans und die Vorgehensweise
von Verteilungsstrategien kann in [Klo2002, KLK2002] nachgelesen werden.
33

KAPITEL 4 DAS JSCATTER-SYSTEM
34

5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
5.1 Transformation
In Kapitel 4 wurde darauf eingegangen, dass im JScatter-System ein sequentielles
Programm durch Transformationen in ein im JScatter-Laufzeitsystem
parallel ausführbares Programm transformiert wird. Ziel dieses Abschnittes ist
es herauszuarbeiten, wie statische Programmanalyse beim Transformationsprozess
eingesetzt wird, um die Klassen des zu transformierenden Programms
so vorzubereiten, dass deren Instanzen nach Abschluss der Transformation im
JScatter-Laufzeitsystem migriert bzw. repliziert werden können.
Wie in Abschnitt 2.3 dargestellt wurde, ist es in der Programmiersprache Java
außerhalb der JVM nicht möglich, aktive Objekte (Threads) ohne Verlust von
Informationen zu migrieren. Deshalb unterstützt das JScatter-System keine
Thread-Migration. Durch diese Festlegung muss am ursprünglichen Transformationskonzept
für Klassen, deren Instanzen ein aktive Objekte repräsentieren,
keine Änderungen vorgenommen werden. Alle anderen Klassen müssen
jedoch speziell für Migration bzw. Replikation vorbereitet werden.
Um aktive von passiven Objekten zu unterscheiden, wird Klassenhierachieanalyse
eingesetzt, deren Vorgehensweise im Abschnitt 3.4 vorgestellt wurde.
Für alle Klassen deren Instanzen sich zur Laufzeit passiv verhalten, wurde ein
einheitliches Transformationskonzept zur Unterstützung von Migration und
Replikation entwickelt. Ob ein passives Objekt jedoch zur Laufzeit migriert
oder repliziert wird, entscheidet die eingesetzte Migrationsstrategie (siehe
Abschnitt 5.3).
Durch statische Programmanalyse werden Migrationsstrategien auf Informationen
zur Verfügung gestellt, die als Entscheidungshilfe für Migration oder
Replikation eingesetzt werden können. Die in [MC19992, Rei1997, SH1998,
Lin2002] beschriebenen Strategien nutzen ausschließlich Informationen aus
dynamischer Programmanalyse. Somit stellen Migrationsstrategien, die zusätzlich
auch Ergebnisse aus statische Programmanalyse als Entscheidungshilfe
einsetzen, eine Neuerung im Bereich der Migrationsstrategien dar.
JScatter stellt durch statische Programmanalyse fest, ob die Replikation der
Migration eines Objektes vorzuziehen ist. Ein solcher Fall liegt vor, wenn ein
Objekt nur oder größtenteils unveränderbare bzw. konstante Felder enthält,
oder auf die Felder eines Objektes nur selten schreibend zugegriffen wird. Um
unveränderbare oder konstante Felder in einer Klasse zu identifizieren kommt
die im Abschnitt 3.2.3 beschriebene Immutable-Analyse zum Einsatz. Mit der
Immutable-Objektanalyse (siehe Abschnitt 3.4) werden Objekte, die selten
schreibend zugegriffen werden erkannt und der Migrationsstrategie zur
Replikation vorgeschlagen.
Wie die Ergebnisse aus der statischen Programmanalyse einer Migrationsstrategie
zur Verfügung gestellt werden und die Transformation insgesamt
35

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
realisiert ist, wird in Kapitel 6 beschrieben.
5.2 Migration und Replikation
Das Migrationskonzept basiert auf dem in Kapitel 4 vorgestellten Klassentransformations-Konzept
des JScatter-Systems. Da bei der Klassentransformation
einer Original-Klasse zwischen Instanzen- und Klassenanteil unterschieden
wird, ist es sowohl bei der Migration als auch bei der Replikation
notwendig, für Instanzen- und Klassenanteil unterschiedliche Konzepte zu
verwenden.
Im Folgenden werden zuerst die Konzepte für die Migration und anschließend
die der Replikation vorgestellt.
5.2.1 MIGRATION
Die grundlegende Vorgehensweise bei der Migration eines Objektes kann in
sieben Schritte untergliedert werden:
1. Sperren des zu migrierenden Objektes
2. Warten, bis alle vor der Migration begonnenen Zugriffe auf das zu
migrierenden Objekt abgearbeitet sind
3. Objektzustand serialisieren
4. serialisierten Objektzustand zum Rechner der neuen Platzierung übertragen
5. Objektzustand deserialisieren und Objekt neu Platzieren
6. Objekt an der alten Platzierung durch Stellvertreter des migrierten Objektes
ersetzen
7. Referenzaktualisierung durchführen und alle aufgehaltenen Zugriffe auf das
Objekt an die neue Platzierung weiterleiten
In Systemen bei denen neben der Migration auch noch die Replikation von
Objektes unterstützt wird, sind für die im System platzierten Replikate
Strategien für ihre Behandlung während der Migration des Original-Objektes
vorzusehen. Hierbei sind drei Strategien vorstellbar.
Bei der ersten Strategie werden vor der Serialisierung des zu migrierenden
Objektes alle im System vorhandenen Replikate im System gelöscht. Somit ist
sichergestellt, dass nach der Migration sich an der neuen Platzierung des
Objektes nicht gleichzeitig ein Replikat des Objektes befindet.
Bei der zweiten Strategie ist nur das Replikat an der neuen Platzierung des zu
migrierenden Objektes zu löschen. Diese Strategie hat den Vorteil, dass auch
während der Migration des Original-Objektes über seine Replikate auf dessen
Objektzustand lesend zugegriffen werden kann. Nach der Migration sind
jedoch alle Replikate von der neuen Platzierung des Original-Objektes zu
unterrichten. Auf diese Weise wird sichergestellt, dass Schreibzugriffe auch
36

5.2 MIGRATION UND REPLIKATION
nach der Migration des Objektes an die gültige Platzierung des Objektes
delegiert werden.
Die dritte Strategie ist eine Erweiterung der zweiten Strategie. Enthält ein zu
migrierendes Objekt auf dem Rechner zu dem es migriert werden soll bereits
ein Replikat, so wird das Replikat zum Original erklärt und alle anderen
Replikate davon benachrichtigt. In dieser Strategie werden nur Kosten für das
Setzen des Replikats als Original und für die Benachrichtigung aller anderen
im System befindlichen Replikate der Replikatgruppe verursacht. Somit ist sie
von den drei vorgestellten die effizienteste Strategie.
Bei diesen Überlegungen muss jedoch auch bedacht werden, wann es
überhaupt sinnvoll ist, ein Objekt zu migrieren, wenn es schon Replikate des
Objektes im System gibt. Hierbei kann festgestellt werden, dass es in dieser
Situation nur sinnvoll ist ein Objekt zu migrieren, wenn es häufig schreibend
zugegriffen wird. Häufige Schreibzugriffe auf ein repliziertes Objekt
veranlassen jedoch Kosten zur Aktualisierung der Replikate. Aus diesem
Grund wurde im JScatter-System die erste Strategie, bei der alle Replikate
eines Objektes vor dessen Migration gelöscht werden, favorisiert.
Im folgenden Teil des Abschnittes wird der Ablauf einer Migration im JScatter
beschrieben. Hierbei wird zur Verdeutlichung der Zusammenhänge eine etwas
technischere Terminologie verwendet.
Wie in Kapitel 4 erläutert, repräsentiert ein Cuckoo-Objekt den Instanzenanteil
eines Objektes der sequentiellen Original-Anwendung. In der Abbildung 5.1 ist
die Ausgangssituation einer Migration von Cuckoo-Objekt B1 von Rechner 2
nach Rechner 1 zu sehen.
Rechner 1
A B 1 _Handle
B_InstanceManager_Stub
C
Rechner 3
B 1 _Handle
Rechner 2
B_InstanceManager_Skeleton
B_InstanceManager
Abbildung 5.1: Situation vor dem Umzug von Objekt B1
B 2
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
Auf Rechner 1 befindet sich ein Cuckoo-Objekt A, das über ein lokales
B 1
B_InstanceManager_Stub
RMI / Netzwerk
37

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
B1_Handle, ein B_InstanceManager-Schnittstelle-Paar (Stub und Skeleton)
und den auf Rechner 2 platzierten B_InstanceManager B1 auf Rechner 2
referenziert. Analog stehen die Cuckoo-Objekte C auf Rechner 3 mit B1 und D
auf Rechner 4 mit B2 auf Rechner 2 in referenzieller Verbindung.
In dieser Situation wird von einer Migrationsstrategie der Umzug des Objektes
B1 von Rechner 2 nach Rechner 1 durchgeführt. Hierzu wird B1 serialisiert, auf
Rechner 1 übertragen und lokal als Objekt B1' platziert. Damit alle Zugriffe
über die veraltete B1-Referenz nach der Migration an B1' weitergeleitet
werden, wird die Referenz auf B1 im B_InstanceManager auf Rechner 2
durch eine B1'_Handle-Referenz ersetzt. Das B1_Handle leitet alle Zugriffe
über den B_InstanceManager auf Rechner 1 an B1' weiter (siehe Abbildung
5.2). Mit dem Ersetzen des Cuckoo-Objektes durch ein entsprechendes Handle
ist die Migration abgeschlossen.
Abbildung 5.2: Situation 1 nach dem Umzug von Objekt B1
Wie in Abbildung 5.2 zu sehen ist, werden Zugriffe von A auf B1', obwohl sich
beide Objekt auf Rechner 1 befinden, immer über den B_InstanceManager
auf Rechner 2 durchgeführt. Damit hätte die Migration ihr Ziel – entfernte
durch lokale Zugriffe zu ersetzen – verfehlt, und Zugriffe auf B1' würden
durch Weiterleiten über zwei Handles, zwei InstanceManager sowie zwei
InstanceManager-Schnittstelle-Paare sogar ineffizienter.
Aus diesem Grund wurde eine Lokalitätsoptimierung entwickelt. Sie basiert
auf dem Konzept, beim ersten Zugriff über eine veraltete Referenz nach der
Migration eine Ausnahme auszulösen, das in Doorastha (siehe Abschnitt 2.1.2)
und JavaParty (siehe Abschnitt 2.1.1) verwendet wird. Beim Zugriff von A auf
B1'_Handle wird im B_InstanceManager auf Rechner 2 eine Ausnahme
ausgelöst, die im B1_Handle auf Rechner 1 abgefangen wird. Über die
38
Rechner 1
A B 1 _Handle
B_InstanceManager_Stub
B_InstanceManager_Skeleton
B_InstanceManager
C
Rechner 3
B 1 '
B 1 _Handle
Rechner 2
B_InstanceManager_Skeleton
B 2
B 1 '_Handle
B_InstanceManager
B_InstanceManager_Stub
B_InstanceManager_Stub
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
RMI / Netzwerk

5.2 MIGRATION UND REPLIKATION
Ausnahme erfährt das B1_Handle die Platzierung von B1'. Da sich B1' und A
auf dem selben Rechner befinden, ersetzt das B1_Handle seine Referenz auf
den B_InstanceManager von Rechner 2 durch eine lokale B1_Instance-
Manager-Referenz. Anschließend führt es den misslungenen Zugriff auf B1'
ein zweites mal über die neue Referenz durch. Die Situation nach der Lokalitätsoptimierung
ist in Abbildung 5.3 zu sehen.
Rechner 1
A B 1 _Handle
B_InstanceManager
B_InstanceManager_Skeleton
C
Rechner 3
B 1 '
B 1 _Handle
Rechner 2
B_InstanceManager_Skeleton
B 2
B 1 '_Handle
B_InstanceManager
B_InstanceManager_Stub
B_InstanceManager_Stub
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
RMI / Netzwerk
Abbildung 5.3: Situation 2 nach Umzug von Objekt B1 auf Rechner 2 nach
Rechner 1 und Lokalitätsoptimierung nach erstem Zugriff von
Objekt A auf Objekt B1'
Analog zur Lokalitätsoptimierung werden entfernte Referenzen auf migrierte
Cuckoo-Objekte beim ersten Zugriff nach der Migration aktualisiert. Jedoch
wird anders als bei der Lokalitätsoptimierung nach dem Auslösen der Ausnahme
die alte entfernte InstanceManager-Referenz durch eine neue entfernte
InstanceManager-Referenz ersetzt. Die resultierende Situation nach der
Referenzaktualisierung vom B1_Handle auf Rechner 3 ist in Abbildung 5.4 zu
sehen.
Auf andere B-Objekte, die wie das migrierte B1-Objekt vom B_Instance-
Manager auf Rechner 2 verwaltet werden, hat die Migration keine Auswirkung.
So kann Cuckoo-Objekt D auf Rechner 4 auch während und nach der
Migration von B1 über seine B2_Handle-Referenz auf Cuckoo-Objekt B2 zugreifen.
Wie in Abschnitt 5.1 hervorgehoben wird, wird bei der Transformation einer
Klasse des sequentiellen Original-Programms eine neue Klasse generiert, die
dessen Klassenanteil im parallel ausführbaren JScatter-Programm repräsentiert.
Bei jedem statischen Zugriff in einem sequentiellen Programm beschafft sich
das zugreifende Objekt eine Referenz auf den statischen Anteil des zuzugrei-
39

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
fenden Objektes. Analog hierzu beschafft sich im JScatter-System ein Objekt
bei jedem Zugriff auf ein Klassenanteil-repräsentierendes Objekt jeweils eine
Referenz. Durch dieses Konzept des Abbildens ehemals statischer Referenzen
ist, wie im Folgenden beschrieben, die Referenzaktualisierung von Objekten,
die auf ein den statischen Anteil repräsentierendes Objekt zugreifen einfacher
als bei Objekten, die Instanzenanteil repräsentieren.
Abbildung 5.4: Situation 3 nach Umzug von Objekt B1 auf Rechner 2 nach
Rechner 1 und Lokalitätsoptimierung nach erstem Zugriff von
Objekt A auf Objekt B1' sowie Referenzaktualisierung für B1-
Referenz von Objekt C
So wie ein Cuckoo-Objekt vor der Migration serialisiert wird, geschieht dies
auch mit einem ClassObject-Objekt. Aus dem serialisierten Objekt wird auf
dem Rechner der neuen Platzierung ein ClassObject' erstellt. Ein referenzieller
Zugriff auf ein ClassObject erfolgt im JScatter-System über ein sogenanntes
RuntimeEnvironment-Objekt, das auf jedem Rechner im System genau einmal
vorhanden ist. Jedes RuntimeEnvironment steht über die lokale Node mit allen
anderen Nodes und und allen ClassObject-Instanzen in Verbindung (siehe
Kapitel 4).
Abbildung 5.5: Situation vor dem Umzug von B_ClassObject
40
Rechner 1
A B 1 _Handle
B_InstanceManager
B_InstanceManager_Skeleton
C
Rechner 3
B 1 '
B 1 _Handle
Rechner 1
B_ClassObject_Stub
A C_ClassObject
Rechner 2
B_InstanceManager_Skeleton
B 2
B 1 '_Handle
B_InstanceManager
B_InstanceManager_Stub
B_InstanceManager_Stub
RMI / Netzwerk
D
Rechner 2
B_ClassObject
B_ClassObject_Skeleton
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
RMI / Netzwerk

5.2 MIGRATION UND REPLIKATION
Nach der Migration eines ClassObjects wird, nach der Aktualisierung der
lokalen alten durch die neue ClassObject-Referenz, die Referenzaktualisierung
auf allen Nodes propagiert. Von diesem Zeitpunkt an werden alle Zugriffe
direkt zum neuen ClassObject' weitergeleitet.
Die Abbildungen 5.5 – 5.7 zeigen beispielhaft, wie die Cuckoo-Objekte A und
D sowie ein Klassenanteil-repräsentierendes Objekt C_ClassObject auf das
Klassenanteil-repräsentierende Objekt B_ClassObject vor und nach dessen
Migration zugreifen. In Abbildung 5.6 sind, um das Verständnis des Konzeptes
zu erhöhen, auch die an der Migration beteiligten Objekte der Laufzeitumgebung
eingezeichnet. Auf eine ausführliche Beschreibung wird jedoch verzichtet.
B'_ClassObject
A
Rechner 1
RuntimeEnvironment
B_ClassObject_Stub
Node_Skeleton
RMI / Netzwerk
Node
C_ClassObject
Abbildung 5.6: Situation nach dem Umzug von B_ClassObject vor der
Referenzaktualisierung
Rechner 1
B'_ClassObject_Skeleton
B'_ClassObject
A C_ClassObject
RMI / Netzwerk
Rechner 2
Abbildung 5.7: Situation nach dem Umzug von B_ClassObject
D
Rechner 2
Node_Stub
RuntimeEnvironment
B_ClassObject
B_ClassObject_Skeleton
Grundlegend findet die Migration eines Objektes im JScatter-System nur statt,
wenn es sich um ein migrierbares Objekt handelt. Wie migrierbare und nicht
migrierbare Objekte vor der Laufzeit ermittelt und zur Laufzeit unterschieden
werden, wurde bereits in Abschnitt 5.1 beschrieben. Bevor die Migration eines
Cuckoo-Objekts oder eines ClassObject-Objekts durchgeführt wird, werden
alle Zugriffe, die vor der Migrationsentscheidung begonnen wurden, ausge-
D
B'_ClassObject_Stub
Legende
Referenz zwischen Objekten
der im JScatter-System
parallele ausführbaren
Anwendung
Referenz zwischen Objekten
im JScatter-Laufzeitsystem
bei der Migration
Laufzeitsystem-Objekt
Objekt der parallele
ausführbaren Anwendung
im JScatter-System
41

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
führt. Durch diese Vorgehensweise ist die Konsistenz des Objektzustandes vor
und nach dessen Migration sichergestellt.
5.2.2 REPLIKATION
Ziel dieses Abschnittes ist es, die unterschiedlichen Replikationskonzepte für
Instanzen- und Klassenanteil-repräsentierende Objekte vorzustellen. Hierbei
wird vor allem darauf Wert gelegt, zu zeigen, dass verschiedene Arten von
Migrations- bzw. Replikationsstrategien unterstützt werden.
Abbildung 5.8: Situation nach Replikation von Cuckoo-Objekt B1
Wie schon bei der Migration, dient die in Abbildung 5.1 dargestellte Situation
als Ausgangssituation, jedoch führt die Migrationsstrategie diesmal die Replikation
des Cuckoo-Objektes B1 nach Rechner 1 durch. Auch die Replikation
beginnt mit dem Serialisieren des B1-Objektes. Anschließend wird das serialisierte
Objekt von Rechner 2 auf Rechner 1 übertragen und in die Verwaltungsinstanz
aller B-Replikate auf Rechner 1, den B Replica _InstanceManager eingetragen.
Damit eine Zuordnung der Replikate eines Objektes im JScatter-
System möglich ist, enthält jedes Original-Cuckoo-Objekt eine Referenz auf
ein ReplicaGroup-Objekt. Über ein ReplicaGroup-Objekt sind alle Replikate
des Cuckoo-Objektes über ein zugehöriges InstanceManager-Schnittstellenpaar
erreichbar. Die Situation nach der Replikation von B1 auf Rechner 1 ist in
Abbildung 5.8 zu sehen.
Beim nächsten Lesezugriff von A auf B1 wird im B1_Handle die Frage nach
der Existenz eines lokalen B1 Replica -Objektes positiv beantwortet und der Zugriff
an dieses weitergeleitet. In Abbildung 5.9 ist die auf Rechner 1 resultierende
Objektkonstellation zu sehen. Analog zu der beschriebenen Replikation
von B1 auf Rechner 1 und anschließendem Lesezugriff, stellt Abbildung 5.9 die
42
Rechner 1
B_InstanceManager_Stub
B 1 _Handle
A
B Replica _InstanceManager
Rechner 3
Replica
B1 B Replica _InstanceManager_Skeleton
Rechner 2
B_InstanceManager_Skeleton
B 2
B 1
B_InstanceManager
ReplicaGroup
B Replica _InstanceManager_Stub
B 1 _Handle
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
RMI / Netzwerk
B_InstanceManager_Stub
C

5.2 MIGRATION UND REPLIKATION
Situation nach Erstellen eines B1 Replica -Objektes auf Rechner 3 mit nachfolgenden
Lesezugriff dar.
Die Durchführung von Lesezugriffen ist in allen Replikationsstrategien gleich,
bei Schreibzugriffen können jedoch verschiedene Vorgehensweisen gewählt
werden. Zum Einen sind Strategien vorstellbar, die vor dem Durchführen des
Schreibzugriffes auf das Original alle Replikate der zugehörigen Replikatgruppe
löschen und anschließend den Schreibzugriff ausführen. Beim nächsten
Zugriffsversuch auf ein gelöschtes Replikat wird dann ein neues Replikat vor
dessen Ausführung erstellt. Diese Vorgehensweise wird auch als Invalidierung
bezeichnet.
Rechner 1
B_InstanceManager_Stub
B 1 _Handle
A
B Replica _InstanceManager
Rechner 3
Replica B1 Replica
B1 B Replica _InstanceManager_Skeleton
Rechner 2
B_InstanceManager_Skeleton
B 2
B 1
B Replica _InstanceManager
B_InstanceManager
ReplicaGroup
B Replica _InstanceManager_Stub
B Replica _InstanceManager_Stub
B Replica _InstanceManager_Skeleton
B 1 _Handle
Rechner 4
B_InstanceManager_Stub
D B 2 _Handle
RMI / Netzwerk
B_InstanceManager_Stub
Abbildung 5.9: Situation nach mehrfacher Replikation von B1 und
anschließendem Lesezugriff von A und C auf ihr lokales
B1-Replikat
Eine andere Strategie stellt zur Laufzeit fest, dass durch eine Folge von
Schreibzugriffen auf ein repliziertes Objekt, es für die Effizienz des Systems
besser ist, die Replikation aufzuheben. Auch in diesem Fall müssen alle
Replikate gelöscht werden. Eine dritte Replikationsstrategie kann jedoch ganz
anders vorgehen. Beispielsweise ist vorstellbar, dass nach der Durchführung
des Schreibzugriffs auf ein Original-Objekt der neue Zustand oder auch nur die
Zustandsänderung an alle zur Replikatgruppe gehörenden Replikate weitergeleitet
werden. Jedoch kann man sich auch hybride Strategien vorstellen, die zu
einer Zeit alle Replikate vor Schreibzugriffen löschen und zu einer anderen
Zeit nach Schreibzugriffen die Aktualisierung der Replikatzustände vorsieht.
Das JScatter-System unterstützt die beiden Grundvorgehensweisen, d. h. das
Löschen vor und das Aktualisieren nach dem Durchführen eines Schreibzugriffs.
Hybride Strategien können aus diesen erstellt werden. Auf die Realisie-
C
43

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
rung der Grundvorhergehensweisen wird in Kapitel 6 näher eingegangen.
Wie in Abbildung 5.8 und 5.9 zu sehen ist, werden Zugriffe auf andere, nicht
replizierte B-Cuckoo-Objekte durch eine Replikation eines Objektes nicht beeinflusst.
So kann unabhängig von der Replikation von B1, B2 von D zugegriffen
oder auch die Migration von B2 nach Rechner 4 durchgeführt werden (siehe
Abbildung 5.10).
Abbildung 5.10: Situation nach mehrfacher Replikation von B1 sowie der
Migration von B2 von Rechner 2 nach Rechner 4
Abbildung 5.11: Situation von Replikation von B_ClassObject auf Rechner 1
Analog zur Replikation von Instanzenanteil-repräsentierenden Objekten können
auch Klassenanteil-repräsentierende Objekte unter Berücksichtigung der
Abbildung statischer Zugriffe im JScatter-System durchgeführt werden. Zum
Verdeutlichen sei wiederum das Beispielszenario aus Abbildung 5.5 gegeben.
44
Rechner 1
B_InstanceManager_Stub
B 1 _Handle
A
B Replica _InstanceManager
Rechner 3
Replica B1 Replica B1 B Replica _InstanceManager_Skeleton
Rechner 1
Rechner 2
B 2 '_Handle
B_InstanceManager_Skeleton
B Replica _InstanceManager
B Replica _ClassObject_Skeleton
Node
A
B Replica _ClassObject
B 1
B_InstanceManager
ReplicaGroup
B Replica _InstanceManager_Stub
B Replica _InstanceManager_Stub
B Replica _InstanceManager_Skeleton
Node_Skeleton
C_ClassObject
B_ClassObject_Stub
RMI / Netzwerk
B 1 _Handle
Rechner 2
B Replica _ClassObject_Stub
Node
Node_Stub
B_InstanceManager_Stub
D
Rechner 4
B_InstanceManager_Skeleton
B 1 '
RuntimeEnvironment
B_ClassObject_Skeleton
B_InstanceManager
B 2 _Handle
RMI / Netzwerk
B_InstanceManager_Stub
B_ClassObject
D
C
ReplicaGroup

5.2 MIGRATION UND REPLIKATION
In dieser Situation bestimmt die Migrationsstrategie das B_ClassObject-Objekt
von Rechner 2 auf Rechner 1 zu replizieren. Nach Durchführung der Replikation
besteht die in Abbildung 5.11 dargestellte Objektkonstellation.
Wie auch bei der Replikation von Cuckoo-Objekten enthält das B_Class-
Object eine Referenz auf ein Replikatgruppen-Objekt, über die es alle
Replikate referenziell zugreifen kann. Jedoch erfolgt der Zugriff nicht direkt
über ein Schnittstellenpaar, sondern indirekt über Laufzeitsystem-Objekte.
Nach der Replikation werden alle Lesezugriffe von A oder C_ClassObject
nicht auf das entfernte B_ClassObject-Objekt, sondern auf seiner lokalen
Kopie durchgeführt. Schreibzugriffe werden, wie schon bei der Replikation
Instanzenanteil-repräsentierender Objekte, an das Original weitergeleitet. Hier
kann wiederum bestimmt werden, ob die Replikate vor der Durchführung des
Zugriffes auf das Original gelöscht, oder nach dessen Durchführung die
Zustände der Replikate aktualisiert werden. Auf diese Weise werden auch beim
Klassenanteil beide Grundformen des Verhaltens zum Durchführen von
Schreibzugriffen auf Replikate unterstützt.
Somit wird sowohl bei der Replikation Klassenanteil- als auch Instanzenanteilrepräsentierender
Objekte die Konsistenz aller zur Replikatgruppe eines
Original-Objekts gehörenden Objekte gewahrt.
5.3 Migrationsstrategien
Wie in Abschnitt 5.2 aufgezeigt wurde, gibt es eine große Anzahl verschiedener
Migrationsstrategien. Hierbei gibt es sowohl statische Strategien, die ihre
Entscheidung nicht an das Laufzeitverhalten anpassen, als auch dynamische
Strategien, die beispielsweise eine ehemalige Repliktionsentscheidung revidieren
und die Migration des Objektes veranlassen. Migrationsstrategien können
verschiedene Replikationsstrategien (siehe Abschnitt 5.2.1) verwenden.
Hybride Strategien machen die verwendete Replikationsstrategie von der vorliegenden
Situation im System abhängig. Alle diese Strategien können im
JScatter-System beschrieben werden. Abbildung 5.12 stellt die Zusammenhänge
der identifizierten Migrationsstrategien graphisch dar.
statische Strategie dynamische Strategie
statische Strategie
dynamische Strategie
benutzt
benutzt
Situation 1
Migration Replikationsstrategie 1 Replikationsstrategie 2
Abbildung 5.12: Migrationsstrategien im Überblick
Situation 2
Situation 3
Replikationsstrategie 3
Migrationsstrategien haben neben der eigentlichen Migration bzw. Replikation,
auf die in Abschnitt 5.2 eingegangen wurde, noch weitere Aufgaben, die in
45

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
diesem Abschnitt betrachtet werden.
Eine Aufgabe von Migrationsstrategien ist die Migrationsentscheidung, die auf
statischen und dynamischen Ergebnissen aus der Programmanalyse beruht. Der
Einsatz der statischen Programmanalyse wurde schon in Abschnitt 5.1 betrachtet.
Die dynamische Programmanalyse führt die Migrationsstrategie zur
Laufzeit selbst durch. Auf allgemeine Vorgehensweisen von dynamischen
Programmanalysen wurde bereits im Abschnitt 3.5 eingegangen. Die dynamische
Programmanalyse im JScatter-System wurde für die Unterstützung von
verschiedenen Arten von Migrationsstrategien um einige Funktionalitäten erweitert,
die im Folgenden vorgestellt werden.
Aktive Objekte werden im JScatter-System nicht migriert. Aus diesem Grund
werden Zugriffe auf aktive Objekte auch nicht von der dynamischen
Programmanalyse betrachtet, da diese Informationen nur für die Initiierung
einer Migration von Interesse sind. Auch Zugriffe, die während der
Initialisierung eines Objektes auf ein anderes Objekt durchgeführt werden,
werden vernachlässigt. Initialzugriffe verfälschen das Analyseergebnis bei
Objekten, auf die zur Laufzeit nur selten zugegriffen wird. So kann es bei der
Initialisierung vorkommen, dass eine Methode innerhalb des Objektes häufig
ausgeführt, nach der Initialisierung jedoch nicht mehr verwendet wird. Durch
die Informationserfassung werden diese Zugriffe als lokale Zugriffe gewertet.
Die Anzahl der entfernten Zugriffe auf das Objekt müssen beim Werten von
Initialzugriffen um ein vielfaches höher sein, bevor eine Migration initiiert
wird.
Nach dem Umzug eines Objektes werden die Ergebnisse der dynamischen
Programmanalyse auf dem Rechner der Ursprungsplatzierung gelöscht. Sollte
das Objekt zu einem späteren Zeitpunkt wieder auf den Rechner der Ursprungsplatzierung
migriert werden, so wird das Objekt erneut in die dynamische
Programmanalyse auf dem Rechner aufgenommen.
In [Rei1997] wird eine Replikationsstrategie vorgestellt, bei der nach der
Gesamtanzahl von z. B. 20 Zugriffen die Ergebnisse der dynamischen Programmanalyse
auf ihren Initialwert zurückgesetzt werden. Um Strategien
dieser Art auch im JScatter-System beschreiben zu können, verfügt die dynamische
Analyse über eine Reset-Funktionalität.
Durch Verwenden der Reset-Funktionalität können Strategien besser auf die
aktuelle Situation von Zugriffen zwischen Objekten einer Anwendung
reagieren. So ist es beispielsweise möglich, dass auf ein Objekt zu einer Zeit Z1
häufiger lesend und zu einer späteren Zeit Z2 häufiger schreibend zugegriffen
wird. Während zur Zeit Z1 eine Replikation des Objektes besser wäre, würde
sich zur Zeit Z2 eine Migration zum Schreiberobjekt anbieten oder, wenn die
Schreibzugriffe von mehreren Objekten auf verschiedenen Rechnern ausgehen,
wäre es besser, die Platzierung des Objektes unverändert zu lassen.
Würde jedoch das Objekt zur Zeit Z2, wegen der hohen Anzahl der
46

5.3 MIGRATIONSSTRATEGIEN
Lesezugriffe aus der Zeit Z1, nach jedem Lesezugriff, der nach einem
Schreibzugriff stattfindet repliziert, entsteht ein enormer Datentransfer, der
jedoch durch ein Informations-Reset vermieden werden kann.
Die dynamische Programmanalyse besitzt eine weitere Funktionalität, die auf
der in [Rei1997] beschriebenen Replikationsstrategie beruht. In dieser
Strategie werden die Lese- und Schreibzugriffe auf ein Objekt in ihrem
prozentualen Verhältnis gegenüber gestellt, und auf deren Basis eine Replikationsentscheidung
getroffen. Damit die ersten Zugriffe jedoch noch keine
Replikation auslösen, muss auf ein Objekt eine Mindestanzahl von Zugriffen
erfolgt sein, bevor das Verhältnis der Lese-und Schreibzugriffe bestimmt und
eine Replikationsentscheidung getroffen wird. Auch Strategien dieser Art
können im JScatter-System beschrieben werden.
Replikate können weder migriert noch repliziert werden. Aus diesem Grund
macht es auch keinen Sinn, Zugriffe auf Replikate durch dynamische
Programmanalyse zu erfassen.
Sowohl für die oben beschriebene Reset-Funktionalität wie auch für die
Migration und Replikation können in Migrationsstrategien Schwellwerte
definiert werden. Der Reset-Schwellwert ist in Strategien zum Durchführen
eines Resets der Analyseergebnisse eines Objektes vorgesehen, wenn die
Gesamtanzahl der Zugriffe auf das Objekt dem Reset-Schwellwert entsprechen.
Der Migrations- bzw. Replikationsschwellwert kann vom Schreiber der
Migrationsstrategie unterschiedlich eingesetzt werden. Zum Einen kann er
einen prozentualen Anteil der Schreib- bzw. Lesezugriffe darstellen (siehe
Strategie in [Rei1997]), zum Anderen kann er einen absoluten Wert darstellen
(siehe Strategie in [MC1992]), ab dem ein Objekt migriert bzw. repliziert wird.
Eine weitere Aufgabe von Migrationsstrategien ist der Transfer der zu migrierenden
bzw. replizierenden Objekte. Anders als in Migrationsstrategien, die auf
Betriebssystemebenen arbeiten, ist es im JScatter-System nicht notwendig, für
Objekte verschiedenen Typs verschiedene Transfermechanismen bereitzustellen.
Der Grund hierfür ist der Einsatz des in Java vorhandenen Mechanismus
zum Erstellen von persistenten Objekten durch Serialisierung und Deserialisierung,
mit dem alle Objekte gleich behandelt werden. Die Einhaltung der
Schnittstelle zur Serialisierung wird bei der Transformation der Anwendung
sichergestellt.
Die wohl schwierigste Aufgabe einer Migrationsstrategie ist die Entscheidung,
ob und wann migriert oder repliziert werden soll. Während meiner Recherchen
habe ich festgestellt, dass es keine Migrationsstrategie gibt, die für alle
Anwendungen gleich gute Ergebnisse liefert. Diese Erkenntnis basiert auf der
Feststellung, dass Programme sich sehr stark in ihrem Verhalten unterscheiden
können. Ein Programm P1 kann eine Vielzahl von Objekten enthalten, die nur
selten schreibend aber häufig lesend zugegriffen werden. Ein Programm P2
hingegen kann, wie bei einer Consumer-Producer-Simulation, Objekte abwechselnd
lesend und schreibend zugreifen. Für Programm P1 bringt der
47

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
Einsatz einer Migrationsstrategie M1, die bei häufig auftretenden Lesezugriffen
Replikation einsetzt, einen relativ großen Laufzeitgewinn, da entfernte Zugriffe
lokal ausgeführt werden. Im Programm P2 bringt der Einsatz der Migrationsstrategie
M1 jedoch keine Laufzeitvorteile, sondern verlangsamt im schlechtesten
Fall sogar P2 gegenüber dem sequenziell Fall, da durch die abwechselnden
Lese- und Schreibzugriffe Replikate immer neu erstellt und anschließend
wieder gelöscht werden, oder die Zustandsänderungen an alle Replikate der
Replikatgruppe weitergegeben werden müssen.
Zum Abschluss des Kapitels wird nun das in diesem Abschnitt vorgestellte
Modell, in das in Abschnitt 2.3.3 beschriebene Komponentenmodell für
Migrationsstrategien von GERNS und LIE [GL1994] eingeordnet.
Eine Migrationsstrategie im JScatter-System besteht aus den Komponenten
Informationserfassung, Entscheidung und Transfer. Der Informationserfassungs-Komponente
sind alle Aufgaben zugeordnet, die mit dynamischer und
statischer Programmanalyse in Zusammenhang stehen. Die Entscheidungs-
Komponente entscheidet über Migration oder Replikation eines Objektes. Der
Transferkomponente sind alle Aufgaben zugeordnet, die zum Transfer der
Objekte notwendig sind.
Eine Informationsverteilungs-Komponente ist im JScatter-System nicht vorhanden.
Die Informationsverteilung ist sehr kostenintensiv, da sie dafür verantwortlich
ist, die gesammelten Informationen auf alle beteiligten Rechner zu
verteilen. Für spätere Versionen ist es jedoch leicht möglich, eine solche
Komponente in die Migrationsstrategie zu integrieren.
Zur Informationsverteilung gehört nach GERNS und LIE auch die Initialplatzierung
der Objekte. Hierfür steht im JScatter auf jedem beteiligten
Rechner ein lokaler Verteilungsplan zur Verfügung. Im Zusammenhang mit
Migration muss darauf geachtete werden, dass nach der Migration dem
Verteilungsplan die neue Platzierung des Objektes mitgeteilt wird. Hierfür
müssen zwei Verteilungspläne aktualisiert werden. Zum Einen der Plan auf
dem Rechner der alten Platzierung des Objektes und zum Anderen der Plan auf
der neuen Platzierung des migrierten Objektes. Wird eine solche Aktualisierung
unterlassen, berechnet der Verteilungsplan die Initialplatzierung eines
neuen Objektes auf Grundlage veralteter Informationen.
Eine weitere Hilfe für die Berechnung der Initialplatzierung eines Objektes
durch den Verteilungsplan stellt eine Migrations-History dar. Auf deren
Grundlage kann der Verteilungsplan die Entwicklung der Systemsituation vor
und nach einer Migration auswerten und die Platzierungsentscheidung für ein
neues Objekt berechnen.
Die Ortsauswahl erfolgt im JScatter-System implizit bei der Überschreitung
eines Schwellwertes. Hierbei wird das Objekt zu dem Rechner migriert von
dem als erstes bei einem Zugriff der Migrationsschwellwert überschritten
wurde. Für Replikation verhält es sich analog. Das Objekt, auf das beim Über-
48

5.3 MIGRATIONSSTRATEGIEN
treten des Schwellwertes zugegriffen wurde, ist das zu migrierende Objekt.
Somit ist eine Objektauswahl- sowie eine Ortsauswahl-Komponente im
JScatter implizit vorhanden.
Auch eine Adaptions-Komponente ist im JScatter nicht vorgesehen. Hier gilt
dasselbe wie bei der Informationsverteilung. Die Kosten, die bei der
Berechnung für die Adaption entstehen, z. B. durch Neuronale Netze (siehe
Abschnitt 2.3.4), sind für die Verteilung von Anwendungen für die das
JScatter-System entwickelt wurde zu hoch.
Eine Gegenüberstellung des hier vorgestellten Modells mit dem Modell von
GERNS und LIE ist in Abbildung 5.12 zu sehen.
Informationserfassung
Informationsverteilung
Entscheidung
Objektauswahl
Ortswahl
Transfer
Adaption
Gerns-Lie-Modell
dynamische Programmanalyse
Verteilung von
Informationen
statische Programmanalyse
Initialplatzierung
{Migration | Replikation | Platzierung bleibt}
Auswahl des Objektes
Auswahl der Platzierung
Transfer des Objektes
dynamisches Anpassen der Strategie
Informationserfassung
Verteilungsplan
Entscheidung
Implizit enthalten
Implizit enthalten
Transfer
JScatter-Modell
Abbildung 5.12: Vergleich Migrationsstrategien Gerns-Lie und JScatter
49

KAPITEL 5 EIN MODELL FÜR MIGRATIONSSTRATEGIEN
50

6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
In diesem Kapitel werden ausgewählte Details bei der Realisierung des
Modells von Kapitel 5 näher betrachtet. Hierbei wird vor allem auf den Einsatz
der statischen Programmanalyse eingegangen, einige technische Aspekte bei
der Umsetzung der Migration und der Replikation näher vorgestellt und die
Architektur sowie die Erweiterbarkeit von Migrationsstrategien im JScatter-
System dargelegt.
In der in Kapitel 4 vorgestellten Basisimplementierung von JScatter wurde für
die Kommunikation zwischen den bei der verteilten Ausführung des transformierten
Programms beteiligten Rechnern das RMI von Sun [Sun 2003]
eingesetzt. Während der Realisierung der Migrationsstrategien wurde die
Kommunikation zwischen den Rechnern auf KaRMI [Nes1999] umgestellt.
KaRMI ist eine effiziente Alternative zum RMI von Sun. Es verbessert die
Kommunikation bei entfernten Methodenaufrufen zwischen Rechnern in einem
Netzwerk durchschnittlich um 34% [Nes1999]. Der Umstieg auf KaRMI war
leicht möglich, da seine Schnittstelle zum RMI von Sun kompatibel ist.
6.1 Transformation
6.1.1 ERKENNUNG MIGRIERBARER UND REPLIZIERBARER OBJEKTE
Wie in Abschnitt 5.1 beschrieben wurde, setzt JScatter bei der Transformation
statische Programmanalyse ein. Als Werkzeug hierfür wird die Analyseumgebung
Pauli [Thi2001] eingesetzt. Pauli ist ein Java-Framework, mit dem
unter Einsatz mehrerer Java-Bibliotheken für Java-Anwendungen statische
Programmanalyse durchgeführt werden kann. Jede Programmanalyse ist in
Pauli durch ein Analysemodul realisiert. Statische Programmanalysen, wie
beispielsweise die in Abschnitt 3.4 beschriebene Immutable-Objektanalyse
basieren auf Ergebnissen anderer statischer Programmanalysen. Aus diesem
Grund ist es in Pauli möglich, Analyseergebnisse eines Analysemoduls bei der
Realisierung eines anderen Analysemoduls einzusetzen. Derzeit verfügt Pauli
über 37 Analysemodule.
JScatter setzt die Klassenhierachieanalyse von Pauli ein, um aktive Objekte in
der zu transformierenden Anwendung zu identifizieren. In der Programmiersprache
Java bilden Instanzen der Klasse Thread und deren Unterklassen
sowie alle Instanzen von Klassen, die das Interface Runnable implementieren
zur Laufzeit aktive Objekte. Alle passiven Objekte werden bei der Transformation
für Migration und Replikation speziell vorbereitet. Konkret wird deren
Schnittstelle gegenüber dem im Kapitel 4 vorgestellten Konzept um Methoden
erweitert, die für das Durchführen von Migration und Replikation durch
Migrationsstrategien erforderlich sind.
Damit Zugriffe auf ein Objekt durch die dynamische Programmanalyse gezählt
werden, muss in jeder Zugriffsmethode eines Klassenanteil- oder Instanzenanteil-repräsentierenden
Objekts ein Inkrementierungsaufruf in der dynamische
51

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Programmanalyse durchgeführt werden. Nur Methoden, über die in der
transformierten Anwendung auf ein Feld der ursprünglichen Originalanwendung
zugegriffen wird und Methoden, die in den Klassen der Originalanwendung
vorhanden waren, werden bei der Transformation um einen
Inkrementierungsaufruf erweitert. Hierbei wird im JScatter-System zwischen
Lese-, Schreib- und Nicht-Lese-Oder-Schreibzugriffen unterschieden.
Lesezugriffe sind Zugriffe, bei denen der Wert eines Feldes der ursprünglichen
Originalklasse gelesen wird. Wird ein Feld der Instanz einer ursprünglichen
Originalklasse während des Zugriffes verändert, handelt es sich um einen
Schreibzugriff. Alle Methoden, die weder lesend noch schreibend auf ein Feld
des Objektes zugreifen, sind Nicht-Lese-Oder-Schreibzugriffe. Bei konservativer
Abschätzung können diese Zugriffe als Lesezugriffe gewertet werden,
da sie wie Lesezugriffe den Zustand des zugegriffenen Objektes nicht verändern.
Lese und Schreibzugriffe auf ein Feld werden mittels Def-Use-Analyse
festgestellt.
Ein Inkrementierungsaufruf enthält sowohl die Information, welches Objekt
zugegriffen wurde, als auch die Information, von welchem Objekt aus ein
Objekt zugegriffen wurde. Jedes Objekt ist im JScatter-System über eine
eindeutige ID, die aus dem Namen der Klasse, der IP-Adresse des Rechners
auf dem es platziert ist und einer weiteren Zahl besteht identifizierbar. Durch
diese Informationen kann neben der Zugriffsart (Lese-, Schreib-, Nicht-Lese-
Oder-Schreibzugriff) bei der Auswertung auch zwischen lokalen und
entfernten Zugriffen unterschieden werden.
6.1.2 ERWEITERUNG DES TRANSFORMATIONSKONZEPTES
Um im JScatter-System Migration und Replikation von Objekten zu unterstützen,
wurde das im Abschnitt 4.1 vorgestellte Transformationskonzept
erweitert. Für die Erweiterung implementieren Instanzenanteil-repräsentierende
Objekte das Interface MigrateableCuckoo (siehe Anhang A) und
Felder, die die eindeutige ID des Objektes beschreiben (siehe Abschnitt 6.1.1),
die Replikatgruppe des Objektes enthalten oder für die Steuerung der
Methodenzugriffe im Zusammenhang mit Migration und Replikation benötigt
werden. Auf die Besonderheiten bei Methodenzugriffen wird in den Abschnitten
6.2.1 und 6.3.1 eingegangen.
Für die Migration und Replikation eines Instanzenanteil-repräsentierenden
Objektes wird das Interface Handle durch ein Interface Migrateable-
Handle erweitert und ein Interface MigrateableInstanceManager eingeführt,
das das Interface Remote erweitert (siehe Anhang A).
Alle Klassenanteil-repräsentierenden Objekte implementieren das Interface
MigrateableClassObject, welches ebenfalls das Interface Remote
erweitert. Des Weiteren wurde im JScatter-System eine abstrakte Klasse
AbstractMigrateableClassObject eingeführt, in der alle Felder und
Methoden enthalten sind, die bei allen Klassenanteil-repräsentierenden
52

6.1 TRANSFORMATION
Objekten identisch sind. Auf diese Weise werden die bei der Transformation
zu generierenden Methoden auf die beschränkt, die je nach ClassObject
unterschiedlichen Maschinencode enthalten.
Vor der Migration und der Replikation muss, wie in Abschnitt 5.2 beschrieben,
der Objektzustand des zu migrierenden bzw. zu replizierenden Objektes
serialisiert und anschließend zur neuen Platzierung übertragen werden. Bei der
Objektserialisierung werden neben dem persistenten Zustand des Objektes
auch alle Methoden serialisiert. Um den Zustand eines Objektes zu migrieren
ist es jedoch nur notwendig, die Werte seiner nicht-transienten Felder zu
serialisieren und zu übertragen. Auf diese Weise kann die unnötige Übertragung
der implementierten Methoden gespart werden. Hierbei ist jedoch
wichtig, das die Serialisierung der Felder erst durchgeführt wird, wenn alle vor
der Migrationsentscheidung begonnenen Zugriffe auf das Objekt durchgeführt
sind, und alle während der Migration des Objektes eintreffenden Methodenzugriffe
aufgehalten und erst nach der Migration an der neuen Platzierung des
Objektes ausgeführt werden.
Um nur die notwendigen Teile des Objektes zu übertragen, wurde in Anlehnung
an das Entwurfsmuster Memento [GHJV1995] im JScatter ein
Interface Memento eingeführt. Ein Memento-Objekt speichert den Zustand
eines Objektes und ist nur von seinem zugehörigen Objekt aus zugreifbar.
Für jede Klasse der zu transformierenden Anwendung, deren Instanzen keine
aktiven Objekte sind, werden vier Memento-Klassen generiert. Zwei für den
Klassenanteil und zwei für den Instanzenanteil. Für die Klasse Example im
Beispiel 6.1 werden für den Instanzenanteil die Memento-Klassen Example-
MigrationMemento und ExampleReplikationMemento generiert.
05
10
15
20
class Example
{
transient int value;
private HashMap map;
Example(int value)
{
this.value = value;
this.map = new HashMap();
}
addElem(Object elem)
{ ... }
getElemAt(int i)
{ ... }
numberOfElems()
{ ... }
...
}
Legende
nicht-transientes Feld
eindeutige Objekt-ID
25
30
35
40
45
class ExampleMigrationMemento implements Memento
{
private HashMap map;
ExampleMigrationMemento(HashMap map)
{ this.map = map; }
public HashMap getMap() { return map; }
}
class ExampleReplicationMemento extends
ReplicationMemento
{
private HashMap map;
ExampleReplicationMemento(HashMap map,
int objectID,String objectIP, String className)
{
super(objectID, objectIP, className);
this.map = map;
}
public HashMap getMap() { return map; }
}
Beispiel 6.1: Memento-Klassen Instanzenanteil-repräsentierender Objekte
53

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Die Klasse ExampleMigrationMemento enthält für alle nicht-transienten
Felder der Klasse Example ein äquivalentes private Feld und eine Zugriffsmethode.
Genauso verhält es sich bei der Klasse ExampleReplikation-
Memento, jedoch besitzt sie zusätzlich noch Felder für die eindeutige ID des
Objektes. Da alle ReplikationMemento-Klassen Felder für die eindeutige
ID besitzen, erweitern sie eine gleichnamige abstrakte Klasse, die auch die
notwendigen Zugriffsmethoden besitzt. Durch die Vererbung brauchen bei der
Transformation sowohl die Felder als auch die Zugriffsmethoden der
eindeutigen ID nicht explizit generiert zu werden. Für den Klassenanteil
werden analoge Klassen generiert. Wie Memento-Objekte bei der Migration
und Replikation eingesetzt werden, wird in den Abschnitten 6.2 und 6.3
beschrieben.
1 ..*
Abbildung 6.1: Klassenhierachie einer im JScatter-System migrierbaren und
replizierbaren Klasse Example
Für die Durchführung der Transformation wird BCEL [Dah1998, Dah2001]
54
besitzt
Object
1 ..*
1 ..*
besitzt
besitzt
besitzt
_ExampleMigrationMemento
_ExampleReplicationMemento
1
MigrateableCuckoo
Example
_ExampleHandel
InstanceManager
_ExampleInstanceManager
Serializable
Handle
UnicastRemoteObject
_ExampleInstanceManagerInterface
Memento
{abstract}
ReplicationMemento
MigrateableHandle
_ExampleClassObjectReplicationMemento
Remote
Legende
X Y
X Y
X
n
Y
X
n
Y
_ExampleClassObject
Klasse
Interface
X erweitert Y
X implementiert Y
X referenziert n Y
ClassObject
{abstract}
AbstractMigrateableClassObject
MigrateableClassObject
_ExampleClassObjectInterface
1 ..*
besitzt
_ExampleClassObjectMigrationMemento
1 ..*
ursprüngliche Hierarchie
erweiterte Hierarchie
X erzeugt n Y
besitzt

6.1 TRANSFORMATION
eingesetzt. Mit BCEL kann der Bytecode bestehender Java-Klassen modifiziert
und neue Java-Klassen in Bytecode erzeugt werden.
Die bei der Transformation einer Klasse durch Hinzufügen von Migration und
Replikation entstehende Klassenhierachie und deren Beziehungen untereinander
sind für eine Klasse Example in Abbildung 6.1 dargestellt.
6.1.3 NUTZUNG DER STATISCHEN PROGRAMMANALYSE ZUR LAUFZEIT
In Abschnitt 5.1 wurde darauf hingewiesen, dass bei der Migrationsentscheidung
Ergebnisse aus der statischen Programmanalyse zur Laufzeit verwendet
werden können, um passive Objekte zur Replikation anstelle von Migration
vorzuschlagen. Im Folgenden wird darauf eingegangen, wie die Analyseergebnisse
zur Laufzeit nutzbar gemacht werden, ohne die aufwändigen statischen
Programmanalysen zur Laufzeit durchzuführen.
JScatter-Transformator
Class A
Class B
Class E
Pauli
Immutable-Objektanalyse
Def-Use-Analyse
Klassenhierachieanalyse
Text-Datei
Rechner 1
Class A
Class B
Class E
Daten einlesen
StaticAnalysisResultsManager
Migrationsstrategie
Class C
................
Class B
................ ................
Class A
................ ................
A
................
................ ................
................
................
................
Anwendung
JScatter-Laufzeitumgebung
Class D
Class ................ E
................
................
................
................
Legende
vor der Laufzeit
während der Transformation
zur Laufzeit vor der Ausführung der Anwendung
Rechner 2
Class A
Class B
Class E
Daten einlesen
StaticAnalysisResultsManager
Migrationsstrategie
...........
...........
............
durch Pauli erkanntes
Immutable-Objekt
Abbildung 6.2: Die Aufbewahrung statischer Analyseergebnisse nach ihrer
Ermittlung und ihre Bereitstellung zur Laufzeit
Während der Transformation der Anwendung werden alle Klassen, deren
Objekte immutable sind, durch Immutable-Objektanalyse identifiziert und
deren Namen in einer Text-Datei gespeichert. Beim Start der JScatter-Laufzeitumgebung
werden die Namen aus der Datei in eine Datenstruktur eingelesen.
55

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Soll zur Laufzeit in einer Migrationsstrategie entschieden werden, ein Objekt
zu migrieren oder zu replizieren, kann die Entscheidungsstrategie als Entscheidungshilfe
über die Datenstruktur anfragen, ob die statische Programmanalyse
dieses Objekt zur Replikation vorschlägt oder nicht. Die Abbildung 6.2 zeigt
die Vorgehensweise im Überblick.
Die Schnittstelle zum Bereitstellen der Ergebnisse aus der statischen
Programmanalyse für Entscheidungsstrategien ist sehr einfach gehalten. Es
wäre wünschenswert, bei der Weiterentwicklung des Systems die Schnittstelle
so zu erweitern, dass abhängig vom Kontext in dem ein Objekt zur Laufzeit
verwendet wird, Ergebnisse aus statischer Programmanalyse nutzen zu können,
um über Migration oder Replikation eines Objektes zur Laufzeit zu entscheiden.
6.2 Migration
In Abschnitt 5.2.1 wurde die Vorgehensweise bei der Migration für Instanzenund
Klassenanteil-repräsentierende Objekte vorgestellt. In diesem Abschnitt
werden die einzelnen Schritte bei der Migration ausführlicher beschrieben.
Jedes für die Migration bei der Transformation vorbereitete Objekt besitzt eine
_migrate(int)-Methode. Diese _migrate(int)-Methode wird von der
Migrationsstrategie aufgerufen, wenn die Entscheidungsstrategie die Migrationsentscheidung
für ein Objekt positiv beantwortet hat. Über den Parameter
der Methode legt die Migrationsstrategie den Rechner fest, auf den das Objekt
migriert werden soll.
Beim Ausführen der _migrate(int)-Methode (siehe Abbildung 6.3) wird
das zu migrierende Objekt zuerst als Migration aktiv makiert und alle weiteren
Methodenzugriffe aufgehalten. Bevor mit der Migration des Objektes
begonnen wird, wird solange gewartet, bis alle Methodenzugriffe außer dem,
der die Migration ausgelöst hat, abgearbeitet sind.
Ist diese Situation eingetreten, werden alle auf entfernten Rechnern vorhandenen
Replikate des Objektes gelöscht. Dies ist notwendig, da ein Objekt nach
seiner Migration eine neue eindeutige ID zugewiesen bekommt, und alle
Replikate seiner Replikatgruppe über die gleiche ID verfügen müssen. Durch
das Löschen der Replikate bei der Migration eines Instanzenanteilrepräsentierenden
Objektes wird die Konsistenz zwischen dem zu migrierenden
Objekt und seinen Replikaten gewahrt.
Nachdem die Replikate gelöscht wurden, wird der Objektzustand in ein byte-
Array serialisiert. Hierfür wird die Transfer-Komponente der aktuellen
Migrationsstrategie verwendet. Zum Erzeugen des Objektzustand-Abbildes
besitzt jedes Instanzenanteil-repräsentierende Objekt eine spezielle Methode.
Abhängig vom Objekt erzeugt die Methode ein Abbild des Objektzustandes als
Memento.
Nach der Serialisierung beschafft sich das Objekt eine Referenz auf einen
56

6.2 MIGRATION
entfernten InstanceManager auf dem Rechner, zu dem das Objekt migriert
werden soll. Hierbei wird entweder ein neuer InstanceManager erzeugt oder
die Referenz auf einen existierenden zurückgegeben. Über die InstanceManager-Referenz
wird auf dem Rechner der neuen Platzierung ein neues
Objekt des konkreten Typs erzeugt und anschließend der deserialisierte
Objektzustand gesetzt. Hierfür besitzt jedes MigrateableCuckoo-Objekt
eine Methode, über die der deserialisierte Objektzustand in Form eines
Mementos gesetzt werden kann.
Nach dem Setzen des Zustandes wird das Objekt als migriert gekennzeichnet.
Über diese Kennzeichnung kann eine Migrationsstrategie feststellen, ob das zu
migrierende Objekt schon einmal migriert wurde. Hierdurch kann bei
Ausführen einer Anwendung der sogenannte Ping-Pong-Effekt [GL1994]
vermieden werden. Beim Ping-Pong-Effekt wird eine Objekt zwischen zwei
Rechner hin und her migriert. Erlaubt eine Migrationsstrategie jedoch nur die
Einfach-Migration von Objekten, kann dieser Effekt nicht auftreten.
Nachdem das Objekt als migriert gekennzeichnet ist, wird ein Stellvertreter des
migrierten Instanzenanteil-repräsentierenden Objektes auf dem Rechner der
neuen Platzierung erzeugt. Beim Initialisieren des Stellvertreters wird dem
Objekt an seiner neuen Platzierung die neue eindeutige ID zugewiesen.
Anschließend wird das Handle als migriert gekennzeichnet und die ID des
Rechners zu dem das Objekt migriert wurde gesetzt. Zum Abschluss der
Migration wird das migrierte Objekt im InstanceManager der alten Platzierung
durch den neuen als migriert gekennzeichneten Stellvertreter ersetzt.
Durch die Kennzeichnung des Stellvertreters als migriert, wird beim nächsten
Zugriff auf die alte Platzierung des Objektes im Stellvertreter eine Moved-
Exception ausgelöst, die die neue eindeutige ID des Objektes enthält. Auf
diese Weise wird dem Zugreifer, beim Auslösen der Ausnahme, die neue
Platzierung des Objektes mitgeteilt.
Nach dem die Migration abgeschlossen ist, wird das Objekt wieder auf
Migration inaktive gesetzt. Der Quellcode eines für die Migration vorbereiteten
Instanzenanteil-repräsentierenden Klasse kann in Anhang B nachgeschlagen
werden.
Die Migration eines Klassenanteil-repräsentierenden Objektes läuft bis zum
Serialisieren des Objektzustandes in Form eines Memento-Objektes analog zu
einem Instanzenanteil-repräsentierenden Objekt ab. Jedoch erfolgt der Umzug
und das Ersetzen der alten durch eine neue Referenz auf eine andere Weise ab.
Über die lokale Node wird auf die Node der neuen Platzierung der serialisierte
Objektzustand als byte-Array übertragen. Anschließend wird aus dem byte-
Array über die ObjectTransferer-Komponente der aktuellen Migrationsstrategie
ein Memento erzeugt. Unter Einsatz des Reflektion-Mechanismus von
Java wird ein neues Objekt des Klassenanteil-repräsentierenden Objektes
instanziert und anschließend der deserialisierte Objektzustand in Form eines
57

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Mementos gesetzt. Damit auf das neue Objekt von der entfernten Platzierung
aus zugegriffen werden kann, wird es in KaRMI gebunden und anschließend
die neue Platzierung allen Nodes im JScatter-System bekannt gegeben. Mit der
Bekanntgabe ist die Migration abgeschlossen. Nun wird das alte Objekt auf
Migration inaktiv gesetzt.
In Abschnitt 6.2.1 wird beschrieben, wie während der Migration eines
Objektes eingehende Methodenaufrufe aufgehalten und nach Abschluss der
Migration an die neue Platzierung des Objektes delegiert werden.
6.2.1 METHODENZUGRIFFE
Während der Migration eines Instanzenanteil-repräsentierenden Objektes
werden alle Methodenaufrufe im InstanceManager des Objektes abgefangen.
Nach der Migration werden die Zugriffe durchgeführt. Da zum Abschluss
der Migration das Original-Objekt durch ein Handle, das auf die neue
Platzierung des Objektes verweist, ausgetauscht wurde, werden die Zugriffe
nach der Migration über das Handle ausgeführt. Hier erfolgt dann das schon
mehrmals erwähnte Auslösen der MovedException. Da der Zugreifer immer
über einen Handle auf ein Instanzenanteil-repräsentierendes Objekt zugreift,
und im InstanceManager die MovedException zum aufrufenden Handle
weitergegeben wird, ist es sinnvoll, die MovedException im Handle
abzufangen. Beim Behandeln der abgefangenen MovedException wird eine
Referenzaktualisierung durchgeführt. Hierbei wird per Lokalitätsoptimierung
überprüft, ob sich das Objekt nach der Migration lokal befindet. Andernfalls
wird der Zugriff entfernt über KaRMI ausgeführt.
Bei jeder Methodenausführung wird vor der eigentlichen Abarbeitung der Methode
eine Zählervariable inkrementiert, über die die Anzahl der aktuell in
Abarbeitung stehenden Methodenzugriffe des Objektes gezählt werden. Am
Ende der Methode wird die Zählvariable dekrementiert. Für Methoden ohne
Rückgabewert ist dies kein Problem, jedoch muss für Methoden mit
Rückgabewert dieser zwischengespeichert und anschließend nach der Dekrementierung
dessen Rückgabe erfolgen.
Bei Klassenanteil-repräsentierenden Objekten werden die Methodenaufrufe,
die während der Migration des Objektes erfolgen, direkt in den zugegriffenen
Methoden des zu migrierenden Objektes abgefangen (siehe Beispiel 6.1). Ist
die Migration beendet, wird eine Referenzaktualisierung innerhalb der
Methode durchgeführt und der Methodenaufruf an die neue Platzierung des
Objektes delegiert. Auch bei Klassenanteil-repräsentierenden Objekten wird
die Anzahl der aktiven Methodenzugriffe gezählt. Die Inkrementierung des
Zählers darf jedoch erst nach der Abfrage, ob eine Migration des Objektes
aktuell durchgeführt wird, erfolgen, da es sonst zu einem Deadlock zwischen
auszuführender Migration und auszuführenden Methoden kommen kann. In
einer solchen Situation kann die Migration nicht durchgeführt werden, weil
gerade auf das zu migrierende Objekt zugegriffen wird und die Zugriffe nicht
58

6.2 MIGRATION
ausgeführt werden können, da die Migration des Objektes gerade durchgeführt
wird. Die Dekrementierung der Zugriffszählung erfolgt analog zu Instanzenanteil-repräsentierenden
Objekten.
05
10
15
20
void addElem(Object elem, ...) throws RemoteException
{
while(_isMigrationActive()){} // warten bis Migration beendet ist
_numberOfActivedMethodCalls++; // Anzahl der aktiven Methodenzugriffe inkrementieren
if(_updateReferenz()) // Aktualisierung der Referenz durchführen
{
_updateReferenz = false; // Referenzaktualisierung auf durchgeführt setzen
_ExampleClassObjectInterface _classObject = (_ExampleClassObjectInterface)
RuntimeEnvironment.getClassObject(_getClassName());
// Anzahl der aktiven Methodenzugriffe dekrementieren
_numberOfActivedMethodCalls--;
// Methodenzugriff auf aktualisierter Referenz durchführen
_classObject.addElem(elem, ...);
}
else
{ ... }
}
Beispiel 6.1: Referenzaktualisierung der Methode eines Klassenanteilrepräsentierenden
Objektes
Ein ausführliches Beispiel für Instanzenanteil- und Klassenanteil-repräsentierende
Objekte kann im Anhang B nachgeschlagen werden.
6.3 Replikation
In Abschnitt 5.2.2 wurden zwei grundlegende Replikationsstrategien vorgestellt,
die das JScatter-System unterstützt. In diesem Abschnitt werden zuerst
die Gemeinsamkeiten bei der Realisierung der beiden Strategien vorgestellt,
bevor ihre wesentlichen Unterschiede erläutert werden.
Das Erstellen eines Replikats ist in beiden Replikationsstrategien mit der in
Abschnitt 6.2 geschilderten Vorgehensweise bei Migration vergleichbar. Auch
bei der Replikation, egal ob für Instanzenanteil- oder Klassenanteil-repräsentierende
Objekte, wird das zu replizierende Objekt nach der Replikationsentscheidung
für weitere Methodenzugriffe gesperrt. Bevor mit der Serialisierung
des Objektzustandes begonnen wird, müssen alle vor der Replikationsentscheidung
begonnenen Methodenzugriffe abgearbeitet sein.
Anders als bei der Migration werden bei der Serialisierung des Objektzustandes
in Form eines Mementos zusätzlich zu den nicht-transienten Feldern
des Objektes auch noch dessen eindeutige ID mit serialisiert. Beim Erzeugen
des Replikats auf dem Zielrecher werden die Replikate unabhängig von dem
auf dem Rechner befindlichen Originalen in einer eigenen Datenstruktur
gespeichert. Auf diese Weise können Zugriffe auf Replikate und Zugriffe auf
Originale unterschieden werden. Durch die gemeinsame eindeutige ID des
Original-Objektes und seiner Replikate wird dem auf ein Replikat zugreifenden
Objekt suggeriert, dass es auf ein entferntes Original-Objekt zugreift.
59

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Bevor ein Replikat in die Datenstruktur eingefügt wird, wird es als Replikat
gekennzeichnet. Methodenzugriffe auf als repliziert gekennzeichnete Objekte
werden nicht durch die dynamische Programmanalyse erfasst. Hierdurch ist
sichergestellt, dass ein repliziertes Objekt nicht migriert wird. Die Propagierung
einer Migrationsentscheidung geht immer von der Inkrementierung
eines Methodenzugriffs aus. Hierauf wird in Abschnitt 6.4 näher eingegangen.
Als weiterer Unterschied zur Migration, wird bei der Replikation das Original-
Objekt nicht gelöscht. Nach dem Abschluss einer Replikation werden alle
aufgehaltenen Methodenaufrufe ohne Referenzaktualisierung durchgeführt.
Eine Referenzaktualisierung, nach der der Zugriff auf ein lokal vorhandenes
Replikat durchgeführt würde, hätte einen unnötigen Mehraufwand zur Folge.
Lesezugriffe können zwar über das lokale Replikat stattfinden, aber
Schreibzugriffe würden auch nach einer Referenzaktualisierung auf dem
Original-Objekt ausgeführt. Aus diesem Grund werden nach dem Abschluss
einer Replikation die angehaltenen Zugriffe einfach weiter abgearbeitet.
Wie in Abschnitt 5.2.2 erwähnt, enthält jedes Original-Objekt, für das mindestes
einmal ein Replikat erzeugt wurde, eine Replikatgruppe. Eine Replikatgruppe
wird im JScatter-System durch ein ReplicaGroup-Objekt (siehe
Anhang A) repräsentiert. ReplicaGroup-Objekte von Instanzenanteil-repräsentierenden
Objekten enthalten für jedes Replikat eine Referenz auf einen
InstanceManager_Stub-Objekt. Über die InstanceManager_Stubs
kann ein Original auf seine Replikate zugreifen. Handelt es sich bei dem
Original-Objekt um ein Klassenanteil-repräsentierendes Objekt, enthält das
ReplicaGroup-Objekt ClassObject_Stub-Objekte für Zugriffe auf seine
Replikate.
6.3.1 METHODENZUGRIFFE
Nach der Einführung der Replikation von Objekten im JScatter-System müssen
Lesezugriffe und Schreibzugriffe unterschiedlich behandelt werden. Lesezugriffe
können, wenn ein lokales Replikat existiert, auf diesem ausgeführt
werden. Schreibzugriffe hingegen werden zum Original-Objekt weitergeleitet,
egal, ob ein lokales Replikat existiert oder nicht.
Beispiel 6.2 zeigt den Aufbau einer, einen Schreibzugriff ausführenden
Methode eines Instanzenanteil-repräsentierenden Objekts. Schreibzugriffe
müssen je nach Replikationsstrategie unterschiedlich behandelt werden. Deshalb
wird vor dem Ausführen eines Schreibzugriffes der Typ der auszuführenden
Replikationsstrategie über die aktuelle Migrationsstrategie ermittelt.
Sollen alle Replikate vor dem Durchführen des Schreibzugriffes gelöscht
werden (Strategie: DELETE_REPLICAS_BY_WRITEACCESS), so wird dies
durch einen Aufruf der gleichnamigen Lösch-Methode durchgeführt, bevor der
Schreibzugriff erfolgt. Beim Ausführen der Lösch-Methode werden über die
InstanceManager_Stub-Objekte der Replikatgruppe des Objektes, alle
existierenden Replikate des Objektes in den entfernten InstanceManager-
60

Objekten gelöscht.
05
10
15
20
25
6.3 REPLIKATION
void addElem(Object elem, ...) throws RemoteException, MovedException
{
...
// Replikations-Strategie-Typ beschaffen
int strategieType = RuntimeEnvironment.getMigrationStrategy()
.getDecidionStrategy().getReplicationStrategieType();
// Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Löschen"
if(strategieType == DecidionStrategy.REPLICATIONTYPE_DELETE_REPLICAS_BY_WRITEACCESS)
{
deleteReplicaByWriteAccess(); // Replikate löschen
map.put(elem.toString(), elem); // Zugriff ausführen
}
// Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Aktualisieren"
else if (strategieType ==
DecidionStrategy.REPLICATIONTYPE_UPDATE_REPLICAS_BY_WRITEACCESS)
{
lockReplicaForWriteAccess(); // Replikate für Zugriffe sperren
map.put(elem.toString(), elem); // Zugriff ausführen
updateAndReleaseReplicaForWriteAccess(); // Replikate aktualisieren und freigeben
...
}
Beispiel 6.2: Schreibzugriff-ausführende Methode auf einem Instanzenanteilrepräsentierendem
Objekt
Bei der zweiten Strategie (UPDATE_REPLICAS_BY_WRITEACCESS)
werden die Replikate eines Objektes nach der Durchführung des Schreibzugriffes
aktualisiert. Damit auf Replikaten während der Ausführung des
Schreibzugriffes von zugreifenden Objekten keine inkonsistenten Werte
gelesen werden, werden alle Zugriffe auf Replikate während der Durchführung
eines Schreibzugriffes aufgehalten. Hierfür wird eine Zugriffs-Sperre gesetzt.
Nachdem alle Replikate gesperrt sind, wird der Schreibzugriff auf dem
Original ausgeführt. Anschließend werden alle Replikate nacheinander
aktualisiert und freigegeben. Bei der Aktualisierung wird der Objektzustand
des Original-Objektes als Memento serialisiert und nach der Übertragung zum
Replikat deserialisiert und auf diesem gesetzt. Die Aktualisierung und die
Freigabe eines Replikats finden als atomare Operation statt. Durch diese
Vorgehensweise wird jeweils ein entfernter Zugriff zur Freigabe eines
Replikats nach der Aktualisierung gespart. Hierdurch befinden sich die
Replikate kurzweilig in inkonsistentem Zustand. Dies hat jedoch keine
negativen Folgen für die Ausführung des Programms, da zugreifende Objekte
durch die Sperre den inkonsistenten Zustand nicht lesen können.
Damit Lesezugriffe auch tatsächlich auf lokal existierenden Replikaten
ausgeführt werden, wird bei jedem Zugriff im Handle eines Instanzenanteilrepräsentierenden
Objektes überprüft, ob ein lokales Replikat existiert. Gibt es
jedoch kein lokales Replikat, wird der Lesezugriff über den zugehörigen
InstanceManager an das Original-Objekt weitergeleitet.
Bei Klassenanteil-repräsentierenden Objekten läuft die Vorgehensweise für
beide Replikationsstrategien analog ab. Damit ein Lesezugriff jedoch auf dem
lokal existierenden Replikat ausgeführt wird, muss das Objekt sich eine
61

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Referenz auf das lokale Replikat beschaffen. Hierfür steht eine spezielle
Methode zur Verfügung. Über die erhaltene Referenz wird der Lesezugriff
ausgeführt. Existiert kein lokales Replikat des zu referenzierenden Objektes,
liefert die Methode eine Referenz zum Original-Objekt. Schreibzugriffe
werden immer auf dem Original-Objekt ausgeführt.
Ein ausführliches Quelltext-Beispiel, dass die Unterschiede zwischen Leseund
Schreibzugriffen im Zusammenhang mit Replikation zeigt, kann in
Anhang B nachgeschlagen werden.
6.4 Migrationsstrategien
In diesem Abschnitt wird zum Einen die Architektur und zum Anderen die
Erweiterbarkeit von Migrationsstrategien im JScatter-System erläutert.
Der Aufbau einer Migrationsstrategie unterteilt sich in die in Abschnitt 5.3
identifizierten Komponenten Informationserfassung, Entscheidung und
Transfer. Für die Architektur der Migrationsstrategien wurde das Entwurfsmuster
Strategy [GHJV1995] eingesetzt. Hierdurch sind Migrationsstrategien
dynamisch austauschbar.
Die Informationserfassungs-Komponente führt die dynamische Programmanalyse
aus. Über sie kann eine Migrationsstrategie verschiedene Informationen
über die Zugriffe auf ein Objekt ermitteln. Hierbei wird zwischen
entfernten und lokalen und zwischen Lese-, Schreib- und Nicht-Lese-Oder-
Schreibzugriffen unterschieden (siehe Abschnitt 6.1.1). Somit kann eine
Entscheidungsstrategie sowohl die Anzahl aller lokalen oder entfernten
Zugriffe auf ein Objekt als auch die Anzahl aller Zugriffe von einem konkreten
Rechner aus auf das Objekt ermitteln. Im Anhang C ist ein Beispiel für die von
der Basisimplementierung der Informationserfassungs-Komponente erfassten
Informationen nachzulesen.
Über die Informationserfassungs-Komponente stehen der Entscheidungsstrategie
auch die Ergebnisse aus der statischen Programmanalyse zur Verfügung.
Sie werden über einen StaticAnalysisResultsManager aus einer Text-
Datei eingelesen.
Die Transfer-Komponente einer Migrationsstrategie stellt eine Schnittstelle zur
Serialisierung und Deserialisierung von Memento-Objekten bereit. Des
Weiteren bietet sie eine Schnittstelle an, über die eine Entscheidungsstrategie
die Migration oder Replikation eines Instanzenanteil- oder Klassenanteilrepräsentierenden
Objektes initiieren kann.
Die Entscheidungs-Komponente ist die zentrale Komponente einer Migrationsstrategie.
In ihr erfolgen die Auswertung der durch die Informationserfassungs-
Komponente gewonnenen Informationen. Die Entscheidungsstrategie enthält
eine Schnittstelle, über die die Schwellwerte der Migraionsstrategie zugegriffen
werden können. In der Basisimplementierung sind die Schwellwerte über
einen StrategyPropertiesManager konfigurierbar. Er liest die vordefi-
62

6.4 MIGRATIONSSTRATEGIEN
nierten Werte aus einer Datei ein. Auf diese Weise kann eine Migraionsstrategie
ohne die Implementierung zu verändern für eine auszuführende
Anwendung eingestellt werden.
Eine Migrationsstrategie wird zur Laufzeit durch ein MigrationStrategy-
Objekt repräsentiert. Es enthält eine Schnittstelle zu den drei Komponenten
einer Migraionsstrategie (siehe Abbildung 6.4). Beim Implementieren einer
neuen Migrationsstrategie kann der Programmierer entweder die Schnittstellen
der einzelnen Komponenten selbst implementieren oder deren Basisimplementierung
erweitern bzw. verwenden. Bei den meisten Strategien wird jedoch
nur die Entscheidungsstrategie verändert werden.
MigrationStrategy
+ getInformationRegistration() : InformationRegistration
+ getDecidionStrategy() : DecidionStrategy
+ getObjectTransferer() : ObjectTransferer
Abbildung 6.4: Schnittstelle einer Migrationsstrategie
Eine Entscheidungsstrategie stellt die Methode checkMigration(...)
bereit. Über diese Schnittstelle fordert die Informationserfassungs-Komponente
die aktuelle Entscheidungsstrategie auf, für ein lokal platziertes Objekt die
Migration oder Replikation des Objektes zu überprüfen.
Im JScatter-System ist ein Mechanismus implementiert, mit dem in einer
Entscheidungsstrategie kontrolliert werden kann, dass eine Migration nur dann
stattfindet, wenn zu diesem Zeitpunkt keine andere Objektmigration oder
Objektreplikation erfolgt. Für diesen Mechanismus steht am zentralen Punkt
des Systems, dem RuntimeManager, eine Schnittstelle bereit, die von einer
Entscheidungsstrategie über das lokale RuntimeEnvironment verwendet
werden kann. Zusammenfassend stellt Abbildung 6.5 die Architektur einer
Migrationsstrategie dar.
RuntimeEnvironment
InformationRegistration
DefaultInformationRegistration
StrategyPropertiesManager
Legende
StrategyManager
Klasse
Legende
MigrationStrategy
DefaultMigrationStrategy
DefaultDecidionStrategy
Abbildung 6.5: Architektur einer Migrationsstrategie
+ Sichtbarkeiten public
Interface
Sichtbarkeit Methodenname() : Rückgabewert
X Y
X implementiert Y
Interface X Y X referenziert Y
X Y X erzeugt Y
ObjectTransferer
DefaultObjectTransferer
DecidionStrategy
63

KAPITEL 6 DIE REALISIERUNG DES MODELLS IM JSCATTER-SYSTEM
Über den StrategyPropertiesManager lädt der StrategyManager die
vom Benutzer eingestellte Migrationsstrategie. Die Erzeugung einer Migrationsstrategie
erfolgt über Java-Reflektion. Der StrategyManager ist durch
Einsatz des Entwurfsmusters Singleton [GHJV1995] modelliert. Hierüber ist
sichergestellt, dass im JScatter-System zur Laufzeit alle Migrations- und
Replikationsentscheidungen von der selben Migrationsstrategie durchgeführt
werden.
64

7 EVALUATION
7 EVALUATION
In diesem Kapitel werden die Messergebnisse zweier Beispielsimulationen für
verschiedene Migrationsstrategien vorgestellt. Insgesamt wurden für die
Evaluation 460 Messungen durchgeführt, deren Ergebnisse im Einzelnen im
Anhang D nachgeschlagen werden können.
Die Messergebnisse, welche in den Abschnitten 7.1 und 7.2 vorgestellt werden,
wurden auf unterschiedlichen Rechnersystemen erzielt. Für die Messungen des
Abschnitts 7.1 kamen ein Rechner mit zwei Pentium III Prozessoren mit 900
MHz, ein Rechner mit einem Pentium III Prozessor mit 800 MHz und ein
Rechner mit einem Pentium 4 Prozessor mit 1,70 GHz zum Einsatz. Die Messungen
des Abschnitts 7.2 wurden auf zwei Rechnern mit jeweils einem
Pentium 4 Prozessor mit 1,70 GHz und zwei Rechnern mit jeweils einem Pentium
4 Prozessor mit 2.40 GHz durchgeführt. Zum Zeitpunkt der Messungen
war Java in Version 1.4.2 und das Betriebssystem Linux (Red Hat) auf den
verwendeten Rechnern installiert.
Für die Initialplatzierung der Objekte beider Beispielsimulationen wurde eine
zyklische Verteilungsstrategie eingesetzt. Durch den Einsatz dieser Verteilungsstrategie
wurden die zu verteilenden Objekte bei jeder vergleichbaren
Messung auf den selben Rechnern platziert.
7.1 Unterschiede bei Migration und Replikation
Für die Untersuchung der Unterschiede Instanzenanteil- und Klassenanteilrepräsentierender
Objekte im Zusammenhang mit Migration und Replikation,
wurde eine Simulation namens Post eingesetzt. Diese Simulation besteht aus
drei Objekten, von denen ein Objekt (Posttasche) zwischen zwei nicht migrierbaren
bzw. replizierbaren Thread-Objekten (Post und Briefträger) abwechselnd
lesend und schreibend zugegriffen wird. Die Anwendung simuliert folgende
Situation:
Ein Briefträger trägt die in einer Posttasche befindlichen Briefe aus. Ist
die Posttasche leer, geht er zur Post und lässt sie sich wieder auffüllen.
Ist die Posttasche neu gefüllt, verteilt er alle in ihr befindlichen Briefe.
Nachdem der Briefträger alle Briefe verteilt hat, und auf der Post keine
Briefe mehr vorhanden sind, wird die Post geschlossen.
Bei dieser Simulation können zwei Parameter konfiguriert werden, zum Einen
die Anzahl der in der Posttasche pro Füllung befindlichen Briefe und zum
Anderen die Anzahl der Füllungen der Posttasche.
Durch die Variierung der Anzahl der Briefe pro Füllung wird die Anzahl der
ohne Unterbrechung nacheinander von einem Thread-Objekt stattfindenden
Zugriffe verändert. Im Gegensatz hierzu ändert die Verwendung unterschiedlicher
Werte für die Anzahl der Füllungen der Posttasche, die Anzahl der
Iterationen, der abwechselnd auf die Posttasche zugreifenden Thread-Objekte.
65

KAPITEL 7 EVALUATION
Um die Unterschiede von Instanzenanteil- und Klassenanteil-repräsentierenden
Objekten im Zusammenhang mit Migration und Replikation untersuchen zu
können, wurde die Simulation zweimal implementiert. Hierbei wird die Posttasche
einmal durch ein Instanzenanteil- und einmal durch ein Klassenanteilrepräsentierendes
Objekt dargestellt.
Des Weiteren wurden unterschiedliche Migrations- bzw. Replikationsstrategien
eingesetzt. Die eingesetzte Migrationsstrategie lautet wir folgt:
Überprüfe nach 20 Zugriffen auf ein Objekt, ob die Anzahl der entfernten
Zugriffe vom Rechner des aktuell zugreifenden Objekts aus größer ist,
als die Anzahl aller lokalen Zugriffe auf das zugegriffene Objekt. Ist dies
der Fall, dann migriere das zugegriffene Objekt auf den Rechner des
aktuell zugreifenden Objektes. Sonst brich die Migration ab.
Führe nach 50 Zugriffen ein Reset auf die gesammelten Informationen
aus, und beginne mit der Überprüfung von vorn.
Eine Migration soll jedoch nur stattfinden, wenn aktuell keine Migration
im System durchgeführt wird.
Mehrfachmigration ist erlaubt.
Die beiden Replikationsstrategien sind analog aufgebaut, mit dem Unterschied,
dass statt Migration Replikation durchgeführt wird. Die Replikationsstrategien
unterscheiden sich jedoch untereinander. Die eine Replikationsstrategie setzt
den Replikationstyp DELETE_REPLICAS_BY_WRITEACCESS ein, während
die andere Strategie UPDATE_REPLICAS_BY_WRITEACCESS durchführt.
Die Implementierung aller zur Evaluation verwendeten Strategien inklusive
einer ausführlichen Beschreibung, kann im Anhang E nachgeschlagen
werden.
Abbildung 7.1: Instanzenanteil-repräsentierende Objekte Gesamtübersicht
66
Laufzeit in Millisekunden
275000
250000
225000
200000
175000
150000
125000
100000
75000
50000
25000
0
10 Füllungen der Posttasche
100 1000 5000
Anzahl Briefe pro Posttaschenfüllung
ohne Migration und
Replikation
mit Migration
mit Replikation
DELETE_REPLICAS_BY_
WRITEACCESS
mit Replikation
UPDATE_REPLICAS_BY_
WRITEACCESS

7.1 UNTERSCHIEDE BEI MIGRATION UND REPLIKATION
Um nicht nur den Vergleich der Strategien untereinander durchführen zu
können, wurden auch Messungen ohne Einsatz von Migration oder Replikation
für den verteilten Fall durchgeführt. Die Ergebnisse der Messungen der
Postsimulation für Instanzenanteil-repräsentierende Objekte mit 10 Füllungen
der Posttasche sind im Abbildung 7.1 dargestellt.
Die Abbildung 7.1 zeigt deutlich, dass eine Replikationsstrategie wegen der
vielen Schreibzugriffe für diese Anwendung ungeeignet ist. Jedoch zeigt die
Abbildung auch, dass die Replikationsstrategie mit Aktualisierung der Replikate
bei einem Schreibzugriff vorteilhafter ist, als alle Replikate bei einem
Schreibzugriff zu löschen.
Ein Vergleich der Messergebnisse ohne Migration und Replikation mit den
Ergebnissen der Strategie mit Migration (siehe Abbildung 7.2) zeigt, dass die
Migration mit zunehmender Anzahl der nacheinander folgenden lokale Zugriffe
einen Laufzeitvorteil gegenüber der verteilten Ausführung ohne Migration
und Replikation ergibt.
Laufzeit in Millisekunden
130000
120000
110000
100000
90000
80000
70000
60000
50000
40000
30000
20000
10000
0
10 Füllungen der Posttasche
100 1000 5000
Anzahl Briefe pro Posttaschenfüllung
ohne Migration
und Replikation
mit Migration
Abbildung 7.2: Instanzenanteil-repräsentierende Objekte; Ausschnitt ohne
Replikation
Bei den Messungen der Postsimulation für Klassenanteil-repräsentierende
Objekte mit 10 Füllungen der Posttasche verhält es sich ähnlich (siehe
Abbildung 7.3). Hier ist der Effekt zwischen den unterschiedlichen Replikationsstrategien
jedoch noch deutlicher zu sehen. Auch der Laufzeitvorteil mit
Migration ist gegenüber der verteilten Ausführung der Postsimulation ohne
Migration und Replikation deutlicher zu sehen.
Bei einem Vergleich der in Abbildung 7.2 und Abbildung 7.4 dargestellten
Messergebnisse, kann eindeutig festgestellt werden, dass die Migration Klassenanteil-repräsentierender
Objekte effizienter ist, als die Instanzenanteilrepräsentierender
Objekte. Diese Unterschiede sind leicht zu erklären.
67

KAPITEL 7 EVALUATION
Abbildung 7.3: Klassenanteil-repräsentierende Objekte Gesamtübersicht
Abbildung 7.4: Klassenanteil-repräsentierende Objekte; Ausschnitt ohne
Replikation
Bei der Migration eines Instanzenanteil-repräsentierenden Objektes wird das
migrierte Original-Objekt an seiner alten Platzierung durch einen Stellvertreter
ersetzt. Beim nächsten Zugriff auf das ehemalige Original-Objekt löst der
Stellvertreter, welcher das migrierte Original-Objekt an der alten Platzierung
ersetzt, eine MovedException aus und leitet diese über einen Instance-
Manager zum Stellvertreter an der Platzierung des zugreifenden Objekts
weiter. Anschließend erfolgt eine Referenzaktualisierung und ein erneuter
Versuch des Zugriffs. Dieser Vorgang stellt einen erheblichen, jedoch
notwendigen Aufwand dar.
Bei der Migration eines Klassenanteil-repräsentierenden Objektes hingegen
wird die alte Referenz durch eine neue ersetzt und nach Referenzaktualisierung
direkt auf das Objekt an seiner neuen Platzierung zugegriffen. Wie in den
68
Laufzeit in Millisekunden
450000
400000
350000
300000
250000
200000
150000
100000
50000
0
Laufzeit in Millisekunden
10 Füllungen der Posttasche
100 1000 5000
Anzahl Briefe pro Posttaschenfüllung
35000
32500
30000
27500
25000
22500
20000
17500
15000
12500
10000
7500
5000
2500
0
10 Füllungen der Posttasche
100 1000 5000
Anzahl Briefe pro Posttaschenfüllung
ohne Migration und
Replikation
mit Migration
ohne Migration
und Replikation
mit Migration
mit Replikation
DELETE_REPLICAS_BY_
WRITEACCESS
mit Replikation UPDA-
TE_REPLICAS_BY_WR
ITEACCESS

7.1 UNTERSCHIEDE BEI MIGRATION UND REPLIKATION
Abbildungen 7.5 und 7.6 zu sehen ist, verändert sich dieser Effekt auch nicht,
wenn die Anzahl der Füllungen der Posttasche auf 100 erhöht wird.
Laufzeit in Millisekunden
Abbildung 7.5: Instanzenanteil-repräsentierende Objekte Gesamtübersicht
Laufzeit in Millisekunden
275000
250000
225000
200000
175000
150000
125000
100000
75000
50000
25000
0
650000
600000
550000
500000
450000
400000
350000
300000
250000
200000
150000
100000
50000
0
100 Füllungen der Posttasche
100 500
Anzahl Briefe pro Posttaschenfüllung
100 Füllungen der Posttasche
100 500
Anzahl Briefe pro Posttaschenfüllung
ohne Migration und
Replikation
mit Migration
mit Replikation
DELETE_REPLICAS_BY_
WRITEACCESS
mit Replikation UPDA-
TE_REPLICAS_BY_WR
ITEACCESS
ohne Migration und
Replikation
mit Migration
mit Replikation
DELETE_REPLICAS_BY_
WRITEACCESS
mit Replikation
UPDATE_REPLICAS_BY_
WRITEACCESS
Abbildung 7.6: Klassenanteil-repräsentierende Objekte Gesamtübersicht
Die Abbildungen 7.7 und 7.8 machen jedoch deutlich, dass sowohl bei
Instanzenanteil- als auch bei Klassenanteil-repräsentierenden Objekten erst
nach einer gewissen Anzahl von Zugriffen die Ausführung der Postsimulation
mit Migrationsstrategie gegenüber der verteilten Ausführung ohne Migration
und Replikation Laufzeitvorteile einbringt.
Das bei der Postsimulation verwendete Zugriffsmuster mit vielen Schreibzugriffen
und wenigen Lesezugriffen ist in vielen Consumer-Producer-
Anwendungen zu finden.
69

KAPITEL 7 EVALUATION
Abbildung 7.7: Instanzenanteil-repräsentierende Objekte; Ausschnitt ohne
Replikation
Abbildung 7.8: Klassenanteil-repräsentierende Objekte; Ausschnitt ohne
Replikation
7.2 Eine komplexere Migrationsstrategie
Nach dem in Abschnitt 7.1 die Evaluation einfacher Migrationsstrategien, die
entweder Migration oder Replikation durchführen, vorgestellt wurde, wird in
diesem Abschnitt die Evaluation einer Strategie vorgestellt, die in Abhängigkeit
der Art und der Anzahl der Zugriffe auf eine Objekt entweder Migration
oder Replikation des zugegriffenen Objektes durchführt. Die genaue
Beschreibung der Strategie lautet:
70
Laufzeit in Millisekunden
Laufzeit in Millisekunden
140000
130000
120000
110000
100000
90000
80000
70000
60000
50000
40000
30000
20000
10000
0
35000
32500
30000
27500
25000
22500
20000
17500
15000
12500
10000
7500
5000
2500
0
100 Füllungen der Posttasche
100 500
Anzahl Briefe pro Posttasche
100 Füllungen der Posttasche
100 500
Anzahl Briefe pro Posttasche
ohne Migration und
Replikation
mit Migration
ohne Migration und
Replikation
mit Migration
Wenn 70% aller entfernten Zugriffe vom Rechner des zugreifenden
Objektes größer oder gleich der Summe aus Lese- und Nicht-Lese-Oder-
Schreibzugriffen entspricht, dann Repliziere das zugegriffene Objekt

7.2 EINE KOMPLEXERE MIGRATIONSSTRATEGIE
zum Rechner des zugreifenden Objektes. Ist dies nicht der Fall, dann
überprüfe, ob die Gesamtanzahl der entfernten Zugriffe vom Rechner des
zugreifenden Objektes größer ist, als die Anzahl aller lokalen Zugriffe
des zugegriffenen Objektes. Ist dies der Fall, dann migriere das zugegriffene
Objekt auf den Rechner des zugreifenden Objektes. Sonst
brich die Migration ab.
Führe nach 100 Zugriffen ein Reset auf die gesammelten Informationen
aus, und beginne mit der Überprüfung von vorn.
Eine Migration oder Replikation soll jedoch nur stattfinden, wenn aktuell
keine Migration oder Replikation im System durchgeführt wird.
Mehrfachmigration ist erlaubt.
Wird eine Replikation durchgeführt, dann führe bei einem Schreibzugriff
eine Aktualisierung der Replikate der zugehörigen Replikatgruppe durch.
Für die Evaluation der Strategie wurde folgende Bibliothekensimulation
verwendet:
In einer Universitätsbibliothek stehen Regale mit Büchern verschiedener
Fachbereiche. Jeder Student kann alle Bücher seines Fachbereiches
ausleihen und lesen. Ein Buch kann jedoch nicht gleichzeitig von
mehreren Studenten gelesen werden. Für jeden der sieben Fachbereiche
gibt es eine unterschiedliche Anzahl von Büchern. Nach dem ein Student
die gewünschten Bücher gelesen hat, geht er nach Hause. Haben alle
Studenten die Bibliothek verlassen, wird sie geschlossen.
Bücher werden in der Simulation durch Book-Objekte repräsentiert. Book-
Objekte können nur lesend zugegriffen werden. Bei der Transformation der
Anwendung werden diese Objekte als immutable erkannt und einer Migrationsstrategie
unter Verwendung statischer Analyseergebnisse zur Replikation
vorgeschlagen. BookShelf-Objekte, die in der Simulation Bücherregale darstellen,
werden sowohl lesend als auch schreibend zugegriffen. Durch ein
Lesezugriff kann die Anzahl der Bücher im Regal festgestellt werden. Ein
Schreibzugriff dient dazu, ein Buch aus dem Regal zu entnehmen oder in das
Regal zurückzustellen.
Bei der Ausführung der Simulation wurden je zwei Student-Objekte
(Threads) und ein BookShelf-Objekt pro Fachbereich sowie jeweils eine
unterschiedliche Anzahl von Book-Objekten pro Fachbereich erzeugt. Die
Simulation wurde auf 2, 3 und 4 Rechnern ausgeführt (siehe Abbildung 7.9).
Die Abbildung 7.9 zeigt deutlich, dass der Einsatz der am Anfang dieses
Abschnittes geschilderten Migrationsstrategie bei der Ausführung der Bibliothekensimulation
deutliche Laufzeitvorteile gegenüber der verteilten Ausführung
ohne Migration und Replikation bringt. Bei 3 und 4 Rechnern sind die
erzielten Laufzeitvorteile jedoch wesentlich geringer, als bei der Ausführung
71

KAPITEL 7 EVALUATION
auf 2 Rechnern.
Abbildung 7.9: Ergebnisse der Migrationstrategie bei der Bibliothekensimulation
Der geringere Laufzeitvorteil bei der Ausführung auf 3 und 4 Rechnern ergibt
sich durch mehrere Einflussfaktoren. Während bei 2 Rechnern durch die
Replikation der Book-Objekte die meisten Zugriffe auf die Book-Objekte lokal
ausgeführt werden, müssen bei der Verwendung von 3 und 4 Rechnern
wesentlich mehr Zugriffe erfolgen, bis ein Book-Objekt repliziert wird.
Ein weiterer Grund ist die zyklische Verteilung der Objekte bei ihrer Initialplatzierung.
Während es bei 2 Rechnern öfter vorkommt, dass das zugreifende
Objekt bereits lokal platziert ist, muss bei 3 und 4 Rechnern erst eine
Replikation erfolgen, bevor alle weiteren Zugriffe lokal ausgeführt werden
können.
Wie die Postsimulation enthält auch die Bibliothekensimulation ein in vielen
Anwendungen auftretendes Zugriffsmuster. Im Unterschied zur Postsimulation
werden bei der Bibliothekensimulation nur wenige Schreibzugriffe und viele
Lesezugriffe durchgeführt. Aus diesem Grund sind bei der Postsimulation
Migrationsstrategien mit Migration und bei der Bibliothekensimulation
Migrationsstrategien mit Replikation zum Erzielen eines Laufzeitgewinns
vorteilhafter.
72
Laufzeit in Millisekunden
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
Bibliothekensimulation
2 3 4
Anzahl Rechner
ohne Strategie
mit Strategie

8 ZUSAMMENFASSUNG UND AUSBLICK
8 ZUSAMMENFASSUNG UND AUSBLICK
In dieser Diplomarbeit wurde ein Modell für Migrationsstrategien entwickelt,
das unter Einsatz von statischer und dynamischer Programmanalyse die
Migration und Replikation von Objekten einer verteilt auszuführenden
Anwendung ermöglicht. Die Struktur des entwickelten Modells ist so flexibel
gehalten, dass eine einmal transformierte Anwendung unter Einsatz verschiedener
Strategien ausgeführt werden kann.
Damit bei der Migration eines Objektes nur dessen purer Objektzustand zum
Rechner der neuen Platzierung übertragen wird, wurde in Anlehnung an das
Entwurfsmuster Memento [GHJV1995] ein effizientes Konzept zum Übertragen
eines serialisierten Objektzustandes entwickelt.
Für die Replikation von Objekten werden zwei grundlegende Replikationstypen
unterstützt. Bei dem Einen werden die vorhandenen Replikate bei einem
Schreibzugriff auf dessen Original-Objekt gelöscht. Im Gegensatz hierzu
werden alle vorhandenen Replikate eines Original-Objektes bei dem zweiten
Replikationstyp nach dem Ausführen des Schreibzugriffs aktualisiert.
Für die Evaluation des Modells wurden jeweils eine Basisimplementierung für
die dynamische Programmanalyse und den Objekttransfer, sowie verschiedene
einfache und eine komplexere Entscheidungsstrategie implementiert.
Die Realisierung des Modells wurde im JScatter-System durchgeführt. Hierbei
zeigen erste Messungen, dass schon bei kleinen Anwendungen die Migration
und Replikation von Objekten Laufzeitvorteile gegenüber der verteilten Ausführung
ohne Migration und Replikation einbringen.
Bisher sind jedoch nur wenige, zumeist einfache Migrationsstrategien implementiert.
Somit steht es noch aus, komplexe Strategien zu implementieren
und für Anwendungen verschiedener Zugriffsmuster zu evaluieren.
Damit der Entscheidungsstrategie einer Migrationsstrategie detailierte Ergebnisse
aus der statischen Programmanalyse zur Laufzeit zur Verfügung stehen,
ist es notwendig, eine Konzept zur Repräsentation statischer Programmanalyse-Ergebnisse
zu entwickeln und in das JScatter-System zu integrieren.
Eine weitere vorteilhafte Erweiterung wäre die Realisierung eines History-
Mechanismus zur Speicherung der zur Laufzeit durchgeführten Objektmigrationen.
Auf der Grundlage einer solchen History könnte eine Verteilungsstrategie
die Auswirkungen einer Migrationsentscheidung bestimmen
und die Ergebnisse bei der Initialplatzierung eines Objektes berücksichtigen.
Um die Effizienz der Basisimplementierung der Informationserfassung zu erhöhen,
bietet sich eine effizientere Zählung der Objektzugriffe an. Beispielsweise
bietet die Arbeit von MICHAEL STILLER [Sti2003], der eine effiziente
Instrumentierung entwickelte, hierfür einen Ansatzpunkt.
Bevor jedoch die vorgeschlagenen Verbesserungen in Angriff genommen
werden, muss das um Migration und Replikation erweiterte Transformations-
73

KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK
konzept in den Transformator des JScatter-Systems integriert werden.
74

LITERATUR
LITERATUR
[BH2002] SARA BOUCHENAK, DANIEL HAGIMONT: Zero Overhead Java Thread
Migration. INRIA, Technischer Report RT-0261, Mai 2002.
http://sardes.inrialpes.fr/papers/reports.shtml
[Bor2002] JENS BORRMANN: Replikation statischer Konstanten in JavaParty.
Studienarbeit, Universität Karlsruhe, Institut für Programmstrukturen
und Datenorganisation, Wintersemester 2001/2002.
http://www.ipd.uka.de/JavaParty/papers.html
[BW1994] LARRY BROWN, JIE WU: Dynamic Snooping in a Fault-Tolerant
Distributed Shared Memory. 14h ICDCS, 1994, Seite 218-226.
[Dah1998] MARKUS DAHM: Byte Code Engineering. Freie Universität Berlin,
Institut für Informatik, 1998.
http://bcel.sourceforge.net/downloads/paper.pdf
[Dah2000] MARKUS DAHM: The Doorastha System. Technical report B-1-
2000, Freie Universität Berlin, Berlin 2000.
ftp://ftp.inf.fu-berlin.de/pub/doorastha/report.pdf
[Dah2001] MARKUS DAHM: Byte Code Engineering with the BCEL API.
Technischer Bericht B-17-98, Freie Universität Berlin, Institut
für Informatik, April 2001.
http://bcel.sourceforge.net/downloads/report.pdf
[DW1994] SABINE DENECKE, THOMAS WAHLBUHL: Eine adaptive Komponente
für Objektmigrationssysteme unter Benutzung Neuronaler Netze.
Hildesheimer Informatik-Berichte, 28/94, November 1994.
http://www.mathematik.uni-hildesheim.de/fb4/berichte/
1994.asp
[FFF+2002] MATTHIAS FAUST, MARTIN FREUND, JYRKI FRIEDRICH, MICHAEL
STILLER, MARCO WEISSENBORN, HERMANN WESSELS:
Abschlussbericht der Projektgruppe Verteilung von parallelen
Java-Anwendungen. Universität Paderborn, Fachbereich
Mathematik-Informatik, November 2002.
[GHJV1995] ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, JOHN VLISSIDES:
Design Patterns – Elements of Reusable Object-Oriented Software.
Addison Wesley, 1995.
[GJS1996] JAMES GOSLING, BILL JOY, GUY STEEL: The Java TM Language
Specification. First Edition, Addison-Wesley, 1996.
http://java.sun.com/docs/books/jls/index.html
75

KAPITEL LITERATUR
[Gol1997] MICHAEL GOLM: Design and Implementation of a Meta Architecture
for Java. Diplomarbeit DA-14-02-97, Universität Erlangen-Nürnberg,
IMMD 4, Erlangen 1997.
http://www4.informatik.uni-erlangen.de/Projects/PM/Java/
DA.abs.html
[GL1994] ARND GERNS, JUNG SUN LIE: Diomedes – Objektmigrationsstrategien
für verteilte Umgebungen. Hildesheimer Informatik-
Berichte, 27/94, November 1994.
http://www.mathematik.uni-hildesheim.de/fb4/berichte/
1994.asp
[Jäg1999] MARKUS JÄGER: RepliXa – Ein Framework zur transparenten
anpassbaren Objektreplikation. Studienarbeit, Universität Erlangen-Nürnberg,
IMMD 4, Erlangen 1999.
http://www4.informatik.uni-erlangen.de/Projects/PM/Java/
replixa/
[JGK1999] MARKUS JÄGER, MICHAEL GOLM, JÜRGEN KLEINÖDER: RepliXa – Ein
Framework zur transparenten anpassbaren Objektreplikation.
Universität Erlangen-Nürnberg, IMMD 4, Erlangen 1999.
http://www4.informatik.uni-erlangen.de/TR/pdf/TR-I4-99-
11.pdf
[JLHB1988] ERIC JUL, HENRY LEVY, NORMAN HUTCHINSON, ANDREW BLACK:
Fine- Grained Mobility in the Emerald System. ACM Trans. On
Computer Systems 6(1), Seiten 109 -133, Februar 1988.
http://www.cs.ubc.ca/nest/dsg/emerald.html
[JSN2002] JODE.SOURCEFORGE.NET: Jode – Decompiler und Optimizer for
Java. September 2002.
http://jode.sourceforge.net
[KLK2002] KASTEN KLOHS, DINH KHOI LE, UWE KASTENS: Automatic Distribution
of Multi-Threated Java Programs using Distributed Plans.
Technischer Bericht, Reihe Informatik tr-ri-02-234, Universität
Paderborn, Fachbereich Mathematik und Informatik, 2002.
http://ag-kastens.uni-paderborn.de/literatur/
literatur.all.php
[Klo2002] KARSTEN KLOHS: Analyse nebenläufiger Prozesse zur
Berechnung von Verteilungsstrategien. Diplomarbeit,
Universität Paderborn, Fachbereich Mathematik-Informatik,
Februar 2002.
http://ag-kastens.uni-paderborn.de/literatur/
literatur.all.php
76

LITERATUR
[Lin2002] MARKUS LINDERMEIER: Ein Konzept zur Lastverwaltung in verteilten
objektorientierten Systemen. Doktorarbeit, Technische Universität
München, Fakultät für Informatik – Lehrstuhl für
Rechnertechnik und Rechnerorganisation, Mai 2002.
http://wwwbode.cs.tum.edu/~linderme/publications.html
[Lux1995] WOLFGANG LUX: Adaptierbare Objektmigration und eine Realisierung
im Betriebssystem Birlix. GMD – Berichte, Nr. 252,
Oldenbourg Verlag München 1995.
[Mae1987] PATTIE MAES: Computational Reflection. PhD Thesis, Artifical
Intelligence Laboratory, Vrieje Universiteit, Brüssel 1987.
[MC1992] SILVANO MAFFEIS, CLEMENS H. CAP: Replication Heuristics and
Polling Algorithms for Object Replication and a Replicating
File Transfer Protocol. Institut für Informatik der Universität
Zürich (IFI), IFI TR 92.06, Zürich 1992.
http://www.ifi.unizh.ch/techreports/TR_1992.html
[MPV1991] DEJAN S. MILOJIČIĆ, MILAN PJEVAČ, DUSAN VELAŠEVIČ: Load
Balancing Survey. In: Tagungsberichte EurOpen Autumn 1991
Conference, Seiten 157-172, Budapest, September 1991.
[Nes1999] CHRISTIAN NESTER: Ein flexibles RMI Design für eine effiziente
Cluster Computing Implementierung. Diplomarbeit, Universität
Karlsruhe, Institut für Programmstrukturen und Datenorganisation,
1. Juli 1999.
http://www.ipd.uka.de/JavaParty/papers.html
[NPH1999] CHRISTIAN NESTER, MICHAEL PHILIPPSEN, BERNHARD HAUMACHER:
Effizientes RMI für Java. Universität Karlsruhe, Institut für
Programmstrukturen und Datenorganisation, 1999.
http://www.ipd.uka.de/JavaParty/papers.html
[PH1999] MICHAEL PHILIPPSEN, BERNHARD HAUMACHER: More Effizient Object
Serialization. In: Parallel and Distributed Processing, number
1586 in Lecture Notes in Computer Science, pages 718-732,
Springer Verlag. Puerto Rico, 12. - 16. April 1999.
http://www.ipd.uka.de/JavaParty/papers.html
[PZ1997] MICHAEL PHILIPPSEN, MATTHIAS ZENGER: JavaParty – Transparent
Remote Objects in Java. In: Concurrency: Practice & Experience,
Volume 9, Number 11, Seiten 1225-1242, November
1997.
http://www.ipd.uka.de/JavaParty/papers.html
77

KAPITEL LITERATUR
[PZJ1998] MICHAEL PHILIPPSEN, MATTHIAS ZENGER, MATTHIAS JACOB:
JavaParty – portables paralleles und verteiltes Programmieren
in Java. In: Proc. JIT'98, Java-Informations-Tage 1998, C. H.
Cap (Hrsg.), Seiten 22-38, Frankfurt, 12.-13. November 1998,
Springer Verlag (Serie Informatik Aktuell). November 1998.
http://www.ipd.uka.de/JavaParty/papers.html
[Rei1997] NIELS REIMER: Untersuchung von Strategien für verteiltes Lastund
Ressourcenmanagement. Technische Universität München,
3. Juli 1997.
http://www13.in.tum.de/forschung/publikationen/
rei_evaadambericht.ps
[RP1999] PETER RECHENBERG, GUSTAV POMBERG: Handbuch-Informatik.
2., aktualisierte und erweiterte Auflage, Carl Hanser Verlag
München, Wien, 1999.
[SH1998] MICHAEL SCHRÖDER, FRANZ J. HAUCK: Juggle – Eine verteilte
virtuelle Maschine für Java. Universität Erlangen-Nürnberg,
Lehrstuhl für Betriebssysteme – IMMD IV, Erlangen 1998.
http://www4.informatik.uni-erlangen.de/~fzhauck/
Pub/Doc/1999-jit-juggle.pdf
[Sti2003] MICHAEL STILLER: Unterstützung der automatischen Verteilung
von Java-Programmen durch Laufzeitdaten. Diplomarbeit,
Universität Paderborn, Fakultät für Elektrotechnik, Informatik
und Mathematik, Arbeitsgruppe Programmiersprachen und
Übersetzer, November 2003.
[Sun2001] SUN: Java TM Object Serialization Specification. August 2001.
ftp://ftp.java.sun.com/docs/j2se1.4/serial-spec.pdf
[Sun2003] SUN: Java Remote Methode Invocation Specification. Juli 2003.
ftp://ftp.java.sun.com/docs/j2se1.4/rmi-spec-1.4.pdf
[Thi1999] MICHAEL THIES: Static compositional analysis of libraries in
support of dynamic optimization. Technischer Bericht, Reihe
Informatik tr-ri-99-210, Universität Paderborn Fachbereich
Mathematik-Informatik, August 1999.
http://ag-kastens.uni-paderborn.de/literatur/
literatur.all.php
[Thi2001] MICHAEL THIES: Combining Static Analysis of Java Libraries
with Dynamic Optimization. Dissertation, Universität Paderborn,
April 2001. SHAKER-Verlag, Achen 2002.
[TK1998] MICHAEL THIES, UWE KASTENS: Statische Analyse von
Bibliotheken als Grundlage dynamischer Optimierung. In:
Clemens Cap, Editor, Proceedings JIT'98, Springer Verlag 1998.
78

LITERATUR
[TS2002a] ELI TILEVICH, YANNIS SMARAGDAKIS: J-Orchestra – Automatic Java
Application Partitioning. Center for Experimental Research in
Computer Sciences, College of Computing, Georgia Institut of
Computer Technology, Atlanta, 2002.
http://j-orchestra.org
[TS2002b] ELI TILEVICH, YANNIS SMARAGDAKIS: J-Orchestra – Automatic Java
Application Partitioning. Report. Center for Experimental
Research in Computer Sciences, College of Computing, Georgia
Institut of Computer Technology, Atlanta, 2002.
http://j-orchestra.org
[Veh1992] UWE VEHMEIER: Bewertung von Lastverteilungsverfahren – Eine
Übersicht. Diplomarbeit, Universität Hildesheim, Dezember
1992.
[Zen1997] MATTHIAS ZENGER: Transparente Objektverteilung in Java. Studienarbeit,
Februar 1997.
http://www.ipd.uka.de/JavaParty/papers.html
79

KAPITEL LITERATUR
80

ANHANG A: SCHNITTSTELLEN DER REALISIERUNG
ANHANG A: SCHNITTSTELLEN DER REALISIERUNG
Anhang A.1: Instanzenanteil-repräsentierende Objekte
package de.upb.jscatter.runtime.migration;
import ...;
// Schnittstelle eines migrierbaren Instanzenanteil-repräsentierenden Objektes
public interface MigrateableCuckoo extends Serializable
{
public void _setObjectID(int _objectID); // zum Aktualisieren der _objectID
}
public int _getObjectId();
public void _setObjectIP(String _objectIP); // zum Aktualisieren der _objectIP
public String _getObjectIp();
public void _setClassName(String _className); // zum Setzen des Namens nach Migration
public void _migrated(); // setzt das Cuckoo-Objekt migriert
public boolean _isMigrated(); // Schnittstelle für Einfachmigration
// Schnittstelle zum Ermitteln der aktuell aktiven Methodenzugriffe
public int _numberOfActivedMethodCalls();
// Schnittstelle zum Ermitteln ob das ClassObject aktuell migriert oder repliziert wird
public boolean _isMigrationActive();
// Schnittstelle zum Migrieren eines Cuckoo-Objekts
public Handle _migrate(int destinationNodehostID) throws RemoteException;
// Schnittstelle zum Replizieren eines Cuckoo-Objekts
public void _replicate(int destinationNodehostID) throws RemoteException;
// makiert ein Cuckoo-Objekt als Replikat
public void _replicated();
// gibt an, ob das Cuckoo-Objekt ein Replikat ist
public boolean _isReplicated();
// Schnittstelle für Replikationsstrategie: Replikate-Bei-Schreibzugriff-Löschen
public void deleteReplicaByWriteAccess() throws RemoteException;
// Schnittstelle für Replikationsstrategie: Replikate-Bei-Schreibzugriff-Aktualisieren
public void lockReplicaForWriteAccess() throws RemoteException;
// Schnittstelle für Replikationsstrategie: Replikate-Bei-Schreibzugriff-Aktualisieren
public void updateAndReleaseReplicaForWriteAccess() throws RemoteException;
// sperrt ein Cuckoo-Replikat Aktualisierung des Objektzustandes
public void _lockReplica();
// gibt an, ob das Cuckoo-Replikat aktuell zur Aktualisierung des Objektzustand
// gesperrt ist
public boolean isReplicaLocked();
// Schnittstelle zum Aktualisieren des Objektzustandes eines Cuckoo-Replikats
public void _updateReplica(byte[] serialisedState);
// Erzeugt ein Abbild des Objektzustandes eines Cuckoo-Objekts für dessen Migration
public Memento createMigrationMemento();
// Erzeugt ein Abbild des Objektzustandes eines Cuckoo-Objekts für dessen Replikation
public Memento createReplicationMemento();
// Schnittstelle zum Setzen des Objektzustandes nach Migration eines Cuckoo-Objektes
public void setStateAfterMigration(Memento migrationMemento);
// Schnittstelle zum Aktualisieren des Objektzustandes eines Replikats nach einem
// Schreibzugriff auf ein repliziertes Original-Cuckoo-Objekt
public void updateStateAfterReplication(Memento replicationMemento);
// Schnittstelle zum Setzen des Objektzustandes nach Replikation eines Cuckoo-Objektes
public void setStateAfterReplication(Memento replicationMemento);
81

KAPITEL ANHANG A: SCHNITTSTELLEN DER REALISIERUNG
package de.upb.jscatter.runtime.migration;
import ...;
// Schnittstelle eines Cuckoo-Objekt-Handles
public interface MigrateableHandle extends Handle
{
// Schnittstelle zum Setzen der neuen Platzierung des migrierten Cuckoo-Objekts
public void _setMigratedNodeHostID(int migratedNodeHostID);
}
public void _migrated();// makiert ein Cuckoo-Objekt-Handle als migriert;
// über ein als migriert gekennzeichnetes Cuckoo-Handle-Objekt
// werden alle Zugriffe eines mirgriertes Cuckoo-Objekts an
// dessen neue Platzierung delegiert
package de.upb.jscatter.runtime.migration;
import ...;
// Schnittstelle eines Cuckoo-Objekt-InstanceManagers
public interface MigrateableInstanceManager extends Remote
{
// Schnittstelle zum Löschen eines Cuchoo-Objekt-Replikats
public void removeReplicaInstance(int _objectID, String _objectIP)
throws RemoteException;
}
// Schnittstelle zum Sperren eines Cuchoo-Objekt-Replikats
public void lockReplicaInstance(int _objectID, String _objectIP)
throws RemoteException;
// Schnittstelle zum Aktualisieren und Freigeben eines Cuchoo-Objekt-Replikats
public void updateReplicaInstance(int _objectID, String _objectIP, byte[]
serialisedState) throws RemoteException;
// Schnittstelle zum Ermitteln, ob ein konkretes Cuchoo-Objekt-Replikat lokal existiert
public boolean containsReplicaInstance(int _objectID, String _objectIP)
throws RemoteException;
Anhang A.2: Klassenanteil-repräsentierende Objekte
package de.upb.jscatter.runtime.migration;
import ...;
// Schnittstelle aller migrierbaren ClassObject-Objekte für die Transfer-Komponente
// einer Migrationsstrategie
public interface MigrateableClassObject extends Remote
{
// Schnittstelle zum Migrieren eines ClassObject-Objektes
public void _migrate(int destinationNodehostID) throws RemoteException;
}
// Schnittstelle zum Replizieren eines ClassObject-Objektes
public void _replicate(int destinationNodehostID) throws RemoteException;
// Schnittstelle zum Ermitteln, ob das ClassObject-Objekt bereits migriert wurde;
// nur für Migrationsstrategien mit Einfachmigration von Interesse
public boolean _isMigrated() throws RemoteException;
// Schnittstelle zum Sperren eines ClassObject-Replikats eines ClassObject-Objekts.
public void lockReplicaInstance() throws RemoteException;
// Schnittstelle zum Aktualisieren eines ClassObject-Replikats eines
// ClassObject-Objekts.
public void updateReplicaInstance(byte[] serialisedState) throws RemoteException;
package de.upb.jscatter.runtime.migration;
import ...;
// Oberklasse aller migrierbaren ClassObject-Objekte des JScatter-Systems
public abstract class AbstractMigrateableClassObject extends ClassObject implements Remote
{
private int _objectID = -1; // Teil der eindeutigen ID eines migrierbaren ClassObjects
82
private String _objectIP; // Teil der eindeutigen ID eines migrierbaren ClassObjects
private String _className; // Teil der eindeutigen ID eines migrierbaren ClassObjects

ANHANG A.2: KLASSENANTEIL-REPRÄSENTIERENDE OBJEKTE
protected boolean _isMigrated = false; // gibt an, ob das Objekt bereits einmal
// migriert wurde
protected boolean _isMigrationActive = false; // gibt an, ob das Objekt gerade
// migriert wird
protected int _numberOfActivedMethodCalls = 0; // gibt die Anzahl der zur Zeit aktiven
// Methodenzugriffe auf das Objekt an
protected boolean _updateReferenz = false; // gibt an, dass die Objektreferenz
// (nach einer Migration) vor der Methodenausführung aktualisiert werden muss
private ReplicaGroup replicaGroup; // Enthält Replikatgruppe des ClassObjectes,
// wenn vorhanden
private boolean _isReplicated = false; // gibt an, ob das ClassObject ein Replikat ist
protected boolean _isReplicaLocked = false; // gibt an, ob das Object für die
// Aktualisierung seiner Replikate gesperrt ist
public AbstractMigrateableClassObject(String _className) throws RemoteException
{
super();
this._className = _className;
_objectIP = RuntimeEnvironment.localNode.getIp();
}
// Schnittstelle zum Migrieren eines ClassObject-Objektes
public final void migrate(int destinationNodehostID) throws RemoteException
{
_isMigrationActive = true; // Objekt als Migration zur Zeit Aktiv markieren
}
// warten bis alle vor der Migrationsentscheidung begonnenen Methodenzugriffe
while(_numberOfActivedMethodCalls() > 1){} // abgearbeitet sind
deleteReplicaByWriteAccess(); // vorhandene Replikate löschen
// Objektzustand über Memento serialisieren
byte[] serializedObject = RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().convertMementoToByteArray(createMemento());
RuntimeEnvironment.localNode.createDeserializedClassObjectAtHost(serializedObject,
destinationNodehostID, _getClassName());
_isMigrationActive = false; // Migration als abgeschlossen setzen
// Schnittstelle zum Replizieren eines ClassObject-Objektes
public final void replicate(int destinationNodehostID) throws RemoteException
{
_isMigrationActive = true; // Objekt als Migration zur Zeit Aktiv markieren
}
while (_numberOfActivedMethodCalls() > 1) {} // warten bis alle vor der
// Migrationsentscheidung begonnenen Methodenzugriffe abgearbeitet sind
// Objektzustand über Memento serialisieren
byte[] serializedObject = RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().convertMementoToByteArray(createMemento());
// Replikat erzeugen und Stub zu Replikat-Gruppe hinzufügen
createRemoteReplica(serializedObject, destinationNodehostID);
_isMigrationActive = false; // Migration als abgeschlossen setzen
_updateReferenz = true; // Referenzen auf das Objekt vor Methodenausführung
// aktualisieren
// Schnittstelle zum Abfragen, ob aktuell die Migration des ClassObject-Objektes
// aktiv ist
public boolean _isMigrationActive() throws RemoteException
{ return _isMigrationActive; }
// makiert das ClassObject als migiert
public void _migrated() throws RemoteException
{
_setObjectIP(RuntimeEnvironment.localNode.getIp()); // _objectIP aktualisieren
}
_isMigrated = true; // ClassObject als bereits einmal migriert setzen
83

KAPITEL ANHANG A: SCHNITTSTELLEN DER REALISIERUNG
84
// Schnittstelle zum Aktualisieren des Objektzustandes eines ClassObject-Replikats
public boolean _updateReferenz() throws RemoteException
{ return _updateReferenz; }
// zum Setzen des Namens nach Migration
public String _getClassName() throws RemoteException
{ return _className; }
// dient zum abfragen der Anzahl der aktuell auf das ClassObject ausgeführten Zugriffe
public int _numberOfActivedMethodCalls() throws RemoteException
{ return _numberOfActivedMethodCalls; }
// Schnittstelle zum Abfragen, ob das ClassObjekt bereits migriert wurde;
// diese Schnittstelle ist nur bei Einfachmigration von Interesse
public boolean isMigrated() throws RemoteException
{ return _isMigrated; }
// zum Aktualisieren der _objectID
public void _setObjectID(int _objectID) { this._objectID = _objectID; }
// zum Aktualisieren der _objectIP
public void _setObjectIP(String _objectIP) { this._objectIP = _objectIP; }
public int _getObjectID() { return _objectID; }
public String _getObjectIP() { return _objectIP; }
// makiert ein ClassObject als Replikat
public void _replicated() { _isReplicated = true; }
// dient zum Abfragen, ob das ClassObject ein Replikat ist
public boolean _isReplicated() { return _isReplicated; }
// Schnittstelle zum Abfragen, ob der Objektzustand des ClassObject-Replikats aktuell
// aktualisiert wird
public boolean isReplicaLocked() { return _isReplicaLocked; }
// sperrt ein Replikat für weitere Zugriffe
public void _lockReplica() { this._isReplicaLocked = true; }
// erzeugt ein ClassObject-Replikat auf einem entfernten Rechner
protected final void createRemoteReplica(byte[] serializedObject,
int destinationNodeHostID) throws RemoteException
{
if(replicaGroup == null) replicaGroup = new ReplicaGroup();
}
// Replikat des ClassObjects nur dann erzeugen, wenn es auf dem entfernten Rechner
// noch kein Exemplar existiert
if (!replicaGroup.hasClassObjectMemberAtHost(destinationNodeHostID))
{
MigrateableRemoteClassObject stub = RuntimeEnvironment.localNode.
createDeserializedClassObjectReplicaAtHost(serializedObject,
destinationNodeHostID, _getClassName());
}
// Replikat zur Replikatgruppe hinzufügen
replicaGroup.addClassObjectMember(destinationNodeHostID, stub);
// für Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Löschen"
protected final void deleteReplicaByWriteAccess() throws RemoteException
{
// alle vorhandenen Replikate des ClassObjects löschen
if (replicaGroup != null)
{
Iterator keys = replicaGroup.getClassObjectMemberKeys();
}
}
while (keys.hasNext())
{
NodeRemoteInterface node = RuntimeEnvironment.localNode.
getNodeWithId(((Integer)keys.next()).intValue());
node.removeClassObjectReplica(_getClassName());
}
replicaGroup = null;

}
ANHANG A.2: KLASSENANTEIL-REPRÄSENTIERENDE OBJEKTE
// für Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Aktualisieren"
protected final void lockReplicaForWriteAccess() throws RemoteException
{
// alle vorhandenen Replikate des ClassObjects für weitere Zugriffe sperren
if (replicaGroup != null)
{
Iterator keys = replicaGroup.getClassObjectMemberKeys();
}
}
while (keys.hasNext())
{
MigrateableRemoteClassObject classObject = replicaGroup.
getClassObjectMember(keys.next());
classObject.lockReplicaInstance();
}
// für Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Aktualisieren"
protected final void updateAndReleaseReplicaForWriteAccess(Memento toSerializeMemento)
throws RemoteException
{
// alle vorhandenen Replikate des ClassObjects aktualisieren
// und für weitere Zugriffe freigeben
if (replicaGroup != null)
{
Iterator keys = replicaGroup.getClassObjectMemberKeys();
}
}
while (keys.hasNext())
{
MigrateableRemoteClassObject classObject = replicaGroup.
getClassObjectMember(keys.next());
}
// Objektzustand serialisieren
byte[] serialisedState = RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().convertMementoToByteArray(toSerializeMemento);
classObject.updateReplicaInstance(serialisedState);
// dient zum Aktualisieren des Objektzustands eines ClassObject-Replikats
public final void updateReplica(byte[] serialisedState) throws RemoteException
{
// übertragenen Objektzustand als Memento deserialisieren
Memento memento = RuntimeEnvironment.getMigrationStrategy().getObjectTransferer().
createMementoForByteArray(serialisedState);
}
setState(memento); // neuen Objektzustand das Replikats über Memento setzen
_isReplicaLocked = false; // ClassObject für weitere Zugriffe freigeben
// Schnittstelle zum Setzen des Objektzustandes nach Replikation
public abstract void setState(Memento memento) throws RemoteException;
// Schnittstelle zum Serialisieren des Zustandes eines ClassObjects als Memento
public abstract Memento createMemento() throws RemoteException;
Anhang A.3: Replikatgruppen-Objekte
package de.upb.jscatter.runtime.migration;
import ...;
// Repräsentiert eine Replikatgruppe im JScatter-System
public class ReplicaGroup
{
// definiert die Datenstrukturen welche die Stubs auf die Replikate eines Cuckoo- oder
// ClassObjects enthalten
private HashMap instanceManagerStubs;
private HashMap classObjectStubs;
public ReplicaGroup() // initialisiert ReplicaGroup-Objekt
{ ... }
// Schnittstelle zum Hinzufügen eines InstanceManager-Stubs
public void addInstanceManagerMember(int destinationNodeHostID, Object instanceManager)
85

KAPITEL ANHANG A: SCHNITTSTELLEN DER REALISIERUNG
}
86
{ ... }
// dient zum Ermitteln, ob auf den angegebenen Rechner ein InstanceManager-Replikat
// existiert
public boolean hasInstanceManagerMemberAtHost(int destinationNodeHostID)
{ ... }
// Schnittstelle zum Hinzufügen eines ClassObject-Stubs
public void addClassObjectMember(int destinationNodeHostID, Object classObject)
{ ... }
// dient zum Ermitteln, ob auf den angegebenen Rechner ein ClassObject-Replikat
// existiert
public boolean hasClassObjectMemberAtHost(int destinationNodeHostID)
{ ... }
// gibt die Schlüssel aller InstanceManager-Stubs der Replikatgruppe zurück
public Iterator getInstanceManagerMemberKeys()
{ ... }
// gibt den InstanceManager-Stub zum übergebenen Schlüssel zurück
public Object getInstanceManagerMember(Object key)
{ ... }
// gibt die Schlüssel aller ClassObject-Stubs der Replikatgruppe zurück
public Iterator getClassObjectMemberKeys()
{ ... }
// gibt den ClassObject-Stub zum übergebenen Schlüssel zurück
public MigrateableClassObject getClassObjectMember(Object key)
{ ... }

ANHANG B: TRANSFORMATIONSBEISPIELE
ANHANG B: TRANSFORMATIONSBEISPIELE
Dieser Anhang gibt jeweils ein Beispiel für die Transformation eines migrierbaren
Instanzenanteil- oder Klassenanteil-repräsentierenden Objektes im
JScatter-System. Hierbei wird jeweils zuerst die Original-Klasse und
anschließend die transformierte Klasse dargestellt.
Anhang B.1: Instanzenanteil-repräsentierende Objekte
### Original ###
package post;
public class LetterCase
{
private int letter;
}
public LetterCase()
{ this.letter = 0; }
public void addLetter(int i)
{ this.letter += i; }
public int nextLetter()
{ this.letter--; return 1; }
public boolean hasLetter()
{ return letter > 0; }
### nach Transformation ###
package post;
import ...;
public class LetterCase implements MigrateableCuckoo
{
public int letter;
private int _objectID = -1;
private String _objectIP;
private String _className;
private boolean _isMigrated = false;
private boolean _isMigrationActive = false;
private int _numberOfActivedMethodCalls = 0;
private boolean _isReplicated = false;
private transient ReplicaGroup _replicaGroup;
private boolean _isReplicaLock = false;
public LetterCase()
{ this.letter = 0; }
public LetterCase(ConstructorParam dummy)
{ }
// Implementierung einer einen Schreibzugriff-ausführenden Methode
public synchronized void addLetter(int i, String _accessObjectName, int
_accessObjectID, String _accessObjectHostIP) throws RemoteException, MovedException
{
// den Zähler der aktiven Methodenzugiffe inkrementieren
_numberOfActivedMethodCalls++;
while(isReplicaLocked()) {} // warten...
// 1. Replikations-Strategie überprüfen
int replicationStrategieType = RuntimeEnvironment.getMigrationStrategy().
getDecidionStrategy().getReplicationStrategieType();
// 1.1 Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Löschen"
if (replicationStrategieType == DecidionStrategy.
REPLICATIONTYPE_DELETE_REPLICA_BY_WRITEACCESS)
{
deleteReplicaByWriteAccess(); // 1.1.1 vorhandene Replikate löschen
}
this.letter += i; // 1.1.2 Schreibzugriff ausführen
87

KAPITEL ANHANG B: TRANSFORMATIONSBEISPIELE
88
}
// 1.2 Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Aktualisieren"
else if (replicationStrategieType == DecidionStrategy.
REPLICATIONTYPE_UPDATE_REPLICA_BY_WRITEACCESS)
{
// wenn Cuckoo-Objekt-Replikate existieren
if (_replicaGroup != null)
{
lockReplicaForWriteAccess(); // 1.2.1 Replikate sperren
}
this.letter += i; // 1.2.2 Schreibzugriff ausführen
// 1.2.3 Replikate aktualisieren und freigeben
updateAndReleaseReplicaForWriteAccess();
}
else
{
this.letter += i; // 2. Schreibzugriff ausführen
}
// 3. Ist das Objekt kein Replikat, dann zähle den Zugriff.
if (!_isReplicated())
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration()
.incrementWriteAccesses(_className, _objectID, _objectIP,
_accessObjectName, _accessObjectID, _accessObjectHostIP);
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
public synchronized int nextLetter(String _accessObjectName, int _accessObjectID,
String _accessObjectHostIP) throws RemoteException, MovedException
{
... // analog zu Methode addLetter(...)
}
// Implementierung einer einen Leszugriff-ausführenden Methode
public synchronized boolean hasLetter(String _accessObjectName, int _accessObjectID,
String _accessObjectHostIP) throws RemoteException, MovedException
{
// den Zähler der aktiven Methodenzugiffe inkrementieren
_numberOfActivedMethodCalls++;
}
while(isReplicaLocked()) {} // warten...
// Ist das Objekt kein Replikat, dann zähle den Zugriff.
if (!_isReplicated())
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration().
incrementReadAccesses(_className, _objectID, _objectIP, _accessObjectName,
_accessObjectID, _accessObjectHostIP);
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
return letter > 0; // Lesezugriff ausführen
public Handle _getHandle()
{ return new _LetterCaseHandle(this); }
// Implementierung der Methoden der Schnittstelle MigratableCuckoo
// (unvollständig) siehe auch Anhang A
...
public Handle _migrate(int deserialisationNodeHostID) throws RemoteException
{
// Cuckoo-Objekt als Migration zur Zeit aktiv markieren
_isMigrationActive = true;
while (_numberOfActivedMethodCalls() > 1) {} // warten...
deleteReplicaByWriteAccess(); // alle vorhandenen Replikate löschen
// serialisieren des Cuckoo-Objektes
byte[] serializedObject = RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().convertMementoToByteArray(createMigrationMemento());
// Referenz auf den entfernten InstanceManager beschaffen
_LetterCaseInstanceManagerInterface destinationNodeInstanceManager =
(_LetterCaseInstanceManagerInterface)

}
ANHANG B.1: INSTANZENANTEIL-REPRÄSENTIERENDE OBJEKTE
RuntimeEnvironment.getInstanceManager(deserialisationNodeHostID, _className);
// Stellvertreter auf migriertes Cuckoo-Object beschaffen
Handle handle = destinationNodeInstanceManager.
createDeserializedInstance(serializedObject, deserialisationNodeHostID);
return handle;
public void _replicate(int destinationNodeHostID) throws RemoteException
{
_isMigrationActive = true; // Cuckoo-Objekt als Migration zur Zeit aktiv markieren
}
while (_numberOfActivedMethodCalls() > 1) {} // warten...
if (_replicaGroup == null) { _replicaGroup = new ReplicaGroup(); }
// Wenn es auf dem entfernten Rechner noch kein Replikat des Objektes
// existiert, dann erzeuge eins. Sonst brich die Replikation ab.
if (!_replicaGroup.hasInstanceManagerMemberAtHost(destinationNodeHostID))
{
// serialisieren des Cuckoo-Objektes
byte[] serializedObject = RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().convertMementoToByteArray(createReplicationMemento());
// Referenz auf entfernten ReplicaGroup-InstanceManager beschaffen.
_LetterCaseInstanceManagerInterface nodeIM =
(_LetterCaseInstanceManagerInterface) RuntimeEnvironment.
getReplicaInstanceManager(destinationNodeHostID, _className);
nodeIM.createDeserializedReplicaInstance(serializedObject);
// Hinzufügen des Replikats zur Replikat-Gruppe.
_replicaGroup.addInstanceManagerMember(destinationNodeHostID, nodeIM);
}
_isMigrationActive = false; // Migrationsaktivierung aufheben
public void _migrated()
{
_isMigrationActive = false; // Cuckoo-Objekt als Migration abgeschlossen markieren
_isMigrated = true; // Cuckoo-Objekt als migriert markieren
}
// Schnittstelle zur Replikationsstrategie: “Bei-Schreibzugriff-Replikate-Löschen“
public void deleteReplicaByWriteAccess() throws RemoteException
{
if (_replicaGroup != null)
{
Iterator keys = _replicaGroup.getInstanceManagerMemberKeys();
}
}
while (keys.hasNext())
{
_LetterCaseInstanceManagerInterface instanceManager =
(_LetterCaseInstanceManagerInterface)
_replicaGroup.getInstanceManagerMember(keys.next());
instanceManager.removeReplicaInstance(_objectID, _objectIP);
}
_replicaGroup = null;
// Schnittstelle zur Replikationsstrategie: “Bei-Schreibzugriff-Replikate-Aktualisieren“
// Teil 1: Replikate für Zugriffe sperren
public void lockReplicaForWriteAccess() throws RemoteException
{
Iterator keys = _replicaGroup.getInstanceManagerMemberKeys();
}
while (keys.hasNext())
{
_LetterCaseInstanceManagerInterface instanceManager =
(_LetterCaseInstanceManagerInterface)
_replicaGroup.getInstanceManagerMember(keys.next());
instanceManager.lockReplicaInstance(_objectID, _objectIP);
}
89

KAPITEL ANHANG B: TRANSFORMATIONSBEISPIELE
}
// Schnittstelle zur Replikationsstrategie: “Bei-Schreibzugriff-Replikate-Aktualisieren“
// Teil 2: Objektzustand der Replikate aktualisieren und für weitere Zugriffe freigeben
public void updateAndReleaseReplicaForWriteAccess() throws RemoteException
{
Memento memento = null;
Iterator keys = _replicaGroup.getInstanceManagerMemberKeys();
}
if(keys.hasNext())
memento = createMigrationMemento(); // nur die Zustandsõnderung übertragen
while (keys.hasNext())
{
_LetterCaseInstanceManagerInterface instanceManager =
(_LetterCaseInstanceManagerInterface)
_replicaGroup.getInstanceManagerMember(keys.next());
byte[] serialisedState = RuntimeEnvironment.getMigrationStrategy()
.getObjectTransferer().convertMementoToByteArray(memento);
instanceManager.updateReplicaInstance(_objectID, _objectIP, serialisedState);
}
// Schnittstelle zum Aktualisieren eines Cuckoo-Objekt-Replikats
public void _updateReplica(byte[] serialisedState)
{
updateStateAfterReplication(RuntimeEnvironment.getMigrationStrategy().
getObjectTransferer().createMementoForByteArray(serialisedState));
this._isReplicaLock = false;
}
public Memento createMigrationMemento()
{ return new _LetterCaseMigrationMemento(letter); }
public Memento createReplicationMemento()
{ return new _LetterCaseReplicationMemento(letter, _objectID, _objectIP, _className); }
// Schnittstelle zum Setzen des Objektzustandes nach einer Migration
public void setStateAfterMigration(Memento migrationMemento)
{
_LetterCaseMigrationMemento memento = (_LetterCaseMigrationMemento)migrationMemento;
this.letter = memento._getLetter();
}
// Schnittstelle zum Aktualisieren des Objektzustandes eines Cuckoo-Objekt-Replikats
// nach einem Schreibzugriff auf das Original-Cuckoo-Objekt
public void updateStateAfterReplication(Memento migrationMemento)
{
_LetterCaseMigrationMemento memento = (_LetterCaseMigrationMemento)migrationMemento;
this.letter = memento._getLetter();
}
// Schnittstelle zum Setzen des Objektzustandes nach einer Replikation eines
// Cuckoo-Objekts
public void setStateAfterReplication(Memento replicationMemento)
{
_LetterCaseReplicationMemento memento = (_LetterCaseReplicationMemento)replicationMemento;
}
this.letter = memento._getLetter();
this._objectID = memento._getObjectID();
this._objectIP = memento._getObjectIP();
this._className = memento._getClassName();
Anhang B.2: Klassenanteil-repräsentierende Objekte
### Original ###
package post2;
public class LetterCase
{
private static int letter = 0;
90
public LetterCase()
{}
public static void addLetter(int i)
{ letter += i; }

}
ANHANG B.2: KLASSENANTEIL-REPRÄSENTIERENDE OBJEKTE
public static int nextLetter()
{ letter--; return 1; }
public static boolean hasLetter()
{ return letter > 0; }
### nach Transformation ###
package post2;
import ...;
public class _LetterCaseClassObject extends AbstractMigrateableClassObject
implements _LetterCaseClassObjectInterface
{
private int letter;
public _LetterCaseClassObject() throws RemoteException
{ super("post2._LetterCaseClassObject"); this.letter = 0; }
// Implementierung einer einen Schreibzugriff-ausführenden Methode
public void addLetter(int i, String _accessObjectName, int _accessObjectID,
String _accessObjectHostIP) throws RemoteException
{
while(_isMigrationActive()){} // warten...
}
// den Zähler der aktiven Methodenzugiffe inkrementieren
_numberOfActivedMethodCalls++;
if(_updateReferenz())
{
_updateReferenz = false;
// Wenn das Objekt migriert ist, leite den Methodenaufruf an das migrierte
// Objekt weiter.
_LetterCaseClassObjectInterface _classObject =
(_LetterCaseClassObjectInterface)RuntimeEnvironment.
getClassObject(_getClassName());
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
_classObject.addLetter(i, _accessObjectName, _accessObjectID,
_accessObjectHostIP);
}
else
{
// 1. Replikations-Strategie überprüfen
int replicationStrategieType = RuntimeEnvironment.getMigrationStrategy().
getDecidionStrategy().getReplicationStrategieType();
}
// 1.1 Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Löschen"
if (replicationStrategieType == DecidionStrategy.
REPLICATIONTYPE_DELETE_REPLICA_BY_WRITEACCESS)
{
deleteReplicaByWriteAccess(); // vorhandene Replikate löschen
this.letter += i; // 1.1.1 Zugriff ausführen
}
// 1.2 Replikationsstrategie: "Replikate-Bei-Schreibzugriff-Aktualisieren"
else if (replicationStrategieType == DecidionStrategy.
REPLICATIONTYPE_UPDATE_REPLICA_BY_WRITEACCESS)
{
lockReplicaForWriteAccess(); // 1.2.1 Replikate sperren
}
this.letter += i; // 1.2.2 Zugriff ausführen
// 1.2.3 Replikate aktualisieren und freigeben
updateAndReleaseReplicaForWriteAccess(createMemento());
// Zugriffszählung durch Informationserfassungs-Komponente
if(!_isReplicated())
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration().
incrementWriteAccesses(_getClassName(), _getObjectID(), _getObjectIP(),
_accessObjectName, _accessObjectID, _accessObjectHostIP);
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
91

KAPITEL ANHANG B: TRANSFORMATIONSBEISPIELE
}
92
public int nextLetter(String _accessObjectName, int _accessObjectID,
String _accessObjectHostIP) throws RemoteException
{
// analog zur Methode addLetter(...);
}
// Implementierung einer einen Lesezugriff-ausführenden Methode
public boolean hasLetter(String _accessObjectName, int _accessObjectID,
String _accessObjectHostIP) throws RemoteException
{
while(_isMigrationActive()){} // warten...
}
// den Zähler der aktiven Methodenzugiffe inkrementieren
_numberOfActivedMethodCalls++;
// Wenn ClassObject migriert oder repliziert wurde Referenz aktualisieren
if(_updateReferenz())
{
_updateReferenz = false;
_LetterCaseClassObjectInterface _classObject = (_LetterCaseClassObjectInterface)
RuntimeEnvironment.getClassObject(_getClassName());
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
return _classObject.hasLetter(_accessObjectName, _accessObjectID,
_accessObjectHostIP);
}
else
{
// Wenn ClassObject kein Replikat ist, dann zähle den Zugriff
if(!_isReplicated())
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration().
incrementReadAccesses(_getClassName(), _getObjectID(), _getObjectIP(),
_accessObjectName, _accessObjectID, _accessObjectHostIP);
}
// den Zähler der aktiven Methodenzugiffe dekrementieren
_numberOfActivedMethodCalls--;
return letter > 0; // Lesezugriff ausführen
public void _migrate(int destinationNodehostID) throws RemoteException
{ migrate(destinationNodehostID); }
public void _replicate(int destinationNodehostID) throws RemoteException
{ replicate(destinationNodehostID); }
public boolean _isMigrated() throws RemoteException
{ return isMigrated(); }
public void lockReplicaInstance() throws RemoteException
{ _lockReplica(); }
public void updateReplicaInstance(byte[] serialisedState) throws RemoteException
{ updateReplica(serialisedState); }
public Memento createMemento()
{ return new _LetterCaseClassObjectMemento(letter); }
public void setState(Memento memento) throws RemoteException
{
_LetterCaseClassObjectMemento classObject = (_LetterCaseClassObjectMemento)memento;
}
this.letter = classObject._getLetter();

ANHANG C: BASISIMPLEMENTIERUNG DER INFORMATIONS
ERFASSUNG
ANHANG C: BASISIMPLEMENTIERUNG DER INFORMATIONS-
ERFASSUNG
In diesem Anhang wird die Organisation der gesammelten Informationen in
der Basisimplementierung der entwickelten Informationserfassungs-Komponente
einer Migrationsstrategie vorgestellt. Für die Beschreibung dient das in
Abbildung Anhang C.1 dargestellte Szenario. Zur Vereinfachung werden nur
Lese- und Schreibzugriffe betrachtet. Nicht-Lese-Oder-Schreibzugriffe (siehe
Abschnitt 6.1.1) können analog ergänzt werden. Die Informationserfassungs-
Komponente macht keine Unterschiede zwischen Instanzenanteil- und Klassenanteil-repräsentierenden
Objekten, sie werden über eine einheitliche
Schnittstelle gezählt.
Rechner
1
Netzwerk / KaRMI
Legende
X
Rechner
2
O
z
Y
B
w
r
A 2
Objekt
C
rw
X greift auf Y zu
A 1
r
rw
z {r, w} | r ≙ Lesezugriff, w ≙ Schreibzugriff
r
w w
D
E
A1
B
C
A2
D
E
B
C
E
Objektzugriffe auf Rechner 1
lokales Objekt
r
2
lokales Objekt
r
0
w
3
w
1
E
entferntes Objekt
r
3
w
0
entferntes Objekt
lokales Objekt entferntes Objekt
Objektzugriffe auf Rechner 2
D
E
lokales Objekt
r
0
r
5
lokales Objekt
r
0
w
2
w
0
w
1
D
r
2
w
0
entferntes Objekt
B
r
3
w
0
entferntes Objekt
lokales Objekt entferntes Objekt
Abbildung Anhang C.1: Beispielszenario der Informationserfassung
Auf der Abbildung Anhang C.1 sind zwei Rechner zu sehen, auf denen jeweils
drei Objekte platziert sind, die sowohl lokal als auch über die Rechnergrenzen
in Interaktion stehen. Hierbei greift beispielsweise Objekt B auf Rechner 1
lesend auf Objekt A2 auf Rechner 2 zu. Des Weiteren ist es für Objekt D auf
Rechner 2 möglich, sowohl lesend als auch schreibend auf Objekt C auf
Rechner 1 zuzugreifen.
93

KAPITEL ANHANG C: BASISIMPLEMENTIERUNG DER INFORMATIONS
ERFASSUNG
Bei Zugriffen auf ein Objekt wird einerseits zwischen zugreifenden Objekten
und andererseits zwischen Lese- und Schreibzugriffen unterschieden. So wurde
im Beispielszenario auf Objekt A1 auf Rechner 1 von Objekt B aus zweimal
lesend und dreimal schreibend, und von Objekt E aus dreimal lesend und kein
mal schreibend zugegriffen. Hierbei ist anzumerken, dass es sich bei den
Zugriffen von Objekt B um lokale Zugriffe handelt, die Zugriffe von Objekt E
hingegen entfernte Zugriffe sind.
In der Basisimplementierung der Informationserfassungs-Komponente wird für
jedes Objekt, welches kein Replikat oder ein aktives Objekt repräsentiert eine
Instanz eines AccessObjectManager-Objekts in eine Datenstruktur aufgenommen.
Somit steht ein AccessObjectManager für ein lokal platziertes
Objekt. Jedes auf ein Objekt zugreifende Objekt ist durch ein sogenanntes
AccessObject dargestellt. Ein AccessObjectManager verwaltet für jedes
auf sein lokal platziertes Objekt zugreifendes Objekt ein AccessObject.
AccessObject-Objekte stellen eine Schnittstelle bereit, über die Zugriffe
untergliedert nach Lese-, Schreib- und Nicht-Lese-Oder-Schreibzugriffen
registriert und abgefragt werden können.
94

ANHANG D: LAUFZEITMESSUNGEN
Werte der verwendeten Rechner:
ANHANG D: LAUFZEITMESSUNGEN
Akkordeon: Pentium 4 Prozessor mit 1,7 GHz
Cello: Pentium 4 Prozessor mit 2,4 GHz
Fidel: Pentium III Prozessor Coppermine mit 800 MHz
Oboe: Pentium III Prozessor Coppermine mit 900 MHz
Pentium III Prozessor Coppermine mit 900 MHz
Panfloete: Pentium 4 Prozessor mit 1,7 GHz
Piano: Pentium 4 Prozessor mit 1,7 GHz
Zither: Pentium 4 Prozessor mit 2,4 GHz
Während der Messungen ist aufgefallen, dass durch Schwankungen im
Netzwerk die erzielten Ergebnisse teilweise stark variieren. Aus diesem Grund
wurden pro Messreihe 15 Messungen durchgeführt und nur die 10 mittleren
Ergebnisse bei der Auswertung berücksichtigt.
Alle Messungen in den folgenden Tabellen sind in Millisekunden angegeben.
Anhang D.1 Beispiel Post: Instanzenanteil
Anzahl der verwendeten Rechner: 3 (Piano, Fidel, Oboe)
ANHANG D.1.1: 10 FÜLLUNGEN DER POSTTASCHE
Tabelle Anhang D.1: Anzahl der Briefe pro Füllung der Posttasche: 100
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 6911 6919 10133 10501
2 6888 6937 9593 10554
3 6875 7480 9625 10250
4 7121 7404 10045 10427
5 6971 7314 10451 10728
6 7095 7451 10054 10347
7 7125 7467 10438 10464
8 7297 7488 10490 10454
9 7435 7430 9944 10654
10 7404 7453 10546 10778
Durchschnitt: 7112, 2 7334, 3 10131, 9 10515, 7
95

KAPITEL ANHANG D: LAUFZEITMESSUNGEN
Tabelle Anhang D.2: Anzahl der Briefe pro Füllung der Posttasche: 1000
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 31346 28650 61161 53779
2 29773 29288 60374 53480
3 30705 29213 61333 53182
4 29104 28965 61782 53667
5 28587 28131 62290 53374
6 33665 29143 62020 53242
7 29439 28078 61466 52832
8 29821 29273 62273 52747
9 29297 29146 61749 53770
10 29532 28558 62338 53012
Durchschnitt: 30126, 9 28844, 5 61678, 6 53308, 5
Tabelle Anhang D.3: Anzahl der Briefe pro Füllung der Posttasche: 5000
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 129792 120710 252573 233722
2 129200 119877 250233 235557
3 127744 120625 251674 232492
4 125516 121197 251167 236557
5 127814 118716 251435 236346
6 127814 121140 251564 237640
7 131939 120216 250917 234588
8 127799 121061 251607 232849
9 129208 121359 250657 233657
10 128925 120574 251097 231457
Durchschnitt: 128575, 1 120547, 5 251292, 4 234486, 5
96

ANHANG D.1.2: 100 FÜLLUNGEN DER POSTTASCHE
ANHANG D.1 BEISPIEL POST: INSTANZENANTEIL
Tabelle Anhang D.4: Anzahl der Briefe pro Füllung der Posttasche: 100
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 30266 32573 60064 54676
2 30093 32100 59074 55644
3 30525 32682 59677 55205
4 30445 33429 59254 55024
5 30436 33244 60629 55778
6 30748 33415 58839 56672
7 30435 33521 60190 55598
8 30616 33501 60058 55330
9 29864 33527 60121 55934
10 30252 32253 60014 56026
Durchschnitt: 30368, 0 33024, 5 59792, 0 55588, 7
Tabelle Anhang D.5: Anzahl der Briefe pro Füllung der Posttasche: 500
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 134227 128938 251553 241074
2 130191 124689 248857 240531
3 126706 127574 250510 236180
4 131597 128955 249763 237994
5 130282 127941 248336 244756
6 129249 128702 254997 238100
7 132639 126800 251302 243646
8 133261 125436 254631 237555
9 131925 125929 247728 240575
10 128978 124323 250764 246464
Durchschnitt: 130905, 5 126928, 7 250844, 1 240687, 5
97

KAPITEL ANHANG D: LAUFZEITMESSUNGEN
Anhang D.2: Beispiel Post: Klassenanteil
Anzahl der verwendeten Rechner: 3 (Piano, Fidel, Oboe)
ANHANG D.2.1: 10 FÜLLUNGEN DER POSTTASCHE
Tabelle Anhang D.6: Anzahl der Briefe pro Füllung der Posttasche: 100
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 1955 1867 12644 6700
2 1930 2142 11950 6533
3 1936 1859 12244 6688
4 1997 2226 11459 6814
5 1927 1893 13279 6730
6 1973 2367 13132 6799
7 2108 2110 13860 6688
8 2014 1827 13573 6915
9 2046 2003 13449 6595
10 1958 1898 13333 6865
Durchschnitt: 1984, 4 2019, 2 12892, 3 6732, 7
Tabelle Anhang D.7: Anzahl der Briefe pro Füllung der Posttasche: 1000
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 7936 2753 127315 40608
2 8101 2788 114212 39938
3 7768 2728 115177 40012
4 7476 2737 132139 39925
5 8131 2776 125592 39513
6 8047 2791 136970 41172
7 8558 2737 121129 39943
8 8101 2719 105855 40507
9 8168 2775 102799 40487
10 8177 2706 107733 39475
Durchschnitt: 8046, 3 2751, 0 118892, 1 40158, 0
98

ANHANG D.2: BEISPIEL POST: KLASSENANTEIL
Tabelle Anhang D.8: Anzahl der Briefe pro Füllung der Posttasche: 5000
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 33049 5481 511122 185200
2 33148 5478 429724 179927
3 33662 5116 406705 182307
4 33166 5421 403083 184318
5 32647 5169 410965 180361
6 33034 6422 405885 182739
7 32771 5474 429900 181379
8 32987 5101 422148 184366
9 32394 5965 548923 179659
10 32526 5127 413911 184345
Durchschnitt: 32938, 4 5475, 4 438236, 6 182460, 1
ANHANG D.2.2 100 FÜLLUNGEN DER POSTTASCHE
Tabelle Anhang D.9: Anzahl der Briefe pro Füllung der Posttasche: 100
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 8594 11961 104390 42067
2 8565 12231 100862 42433
3 8321 11242 101093 41806
4 8596 12917 100819 42608
5 8650 11911 106981 44783
6 8571 12452 90135 43485
7 8362 12771 104751 43685
8 8843 12344 94284 43307
9 8573 11946 106498 42310
10 8658 11443 102478 42205
Durchschnitt: 8573, 3 12121, 8 101229, 1 42868, 9
99

KAPITEL ANHANG D: LAUFZEITMESSUNGEN
Tabelle Anhang D.10: Anzahl der Briefe pro Füllung der Posttasche: 500
Messung ohne Migration
und Replikation
mit Migration mit Replikation
Delete
mit Replikation
Update
1 33690 13523 602040 192122
2 33393 13422 574745 194372
3 34409 13915 595878 190917
4 33628 13271 589697 193471
5 35287 13749 559675 199885
6 32843 13953 643045 195233
7 33653 13658 655737 199768
8 33661 14186 608692 199977
9 34662 13580 630951 204883
10 33594 13892 625103 202668
Durchschnitt: 33882, 0 13714, 9 608556, 3 197329, 6
Anhang D.3: Beispiel Bibliothek
Tabelle Anhang D.11: Zwei Rechner (Akkordeon, Cello)
Messung ohne Strategie mit Strategie
1 59644 28700
2 58278 27225
3 60443 27874
4 63682 30948
5 58490 27736
6 59724 27501
7 59192 27040
8 60823 30069
9 59845 30268
10 58972 27039
Durchschnitt: 59909, 3 28440, 0
100

ANHANG D.3: BEISPIEL BIBLIOTHEK
Tabelle Anhang D.12: Drei Rechner (Akkordeon, Cello, Zither)
Messung ohne Strategie mit Strategie
1 10715 9575
2 10576 9502
3 11579 8930
4 9460 8228
5 10790 8664
6 9401 9230
7 11766 9087
8 11213 9100
9 10214 9652
10 12157 9374
Durchschnitt: 10787, 1 9134, 2
Tabelle Anhang D.13: Vier Rechner (Akkordeon, Cello, Zither, Panfloete)
Messung ohne Strategie mit Strategie
1 9923 8917
2 9643 8339
3 9623 7617
4 9386 8063
5 9804 7363
6 9471 7725
7 9797 8691
8 9445 8907
9 9888 7369
10 9813 8757
Durchschnitt: 9679, 3 8174, 8
101

KAPITEL ANHANG D: LAUFZEITMESSUNGEN
102

ANHANG E: BEISPIELIMPLEMENTIERUNGEN FÜR
ENTSCHEIDUNGSSTRATEGIEN
ANHANG E: BEISPIELIMPLEMENTIERUNGEN FÜR
ENTSCHEIDUNGSSTRATEGIEN
/**
* Entscheidungsstrategie für Migrationsstrategie des Post-Beispiels
* für Migration Instanzenanteil- oder Klassenanteil-repräsentierender Objekte.
*
* Strategiebeschreibung:
* Überprüfe nach 20 Zugriffen auf das Objekt, ob die Anzahl der entfernten
* Zugriffe vom Rechner des aktuell zugreifenden Objekt aus größer ist, als
* die Anzahl aller lokalen Zugriffe auf das zugegriffene Objekt. Ist dies
* der Fall, dann migriere das zugegriffene Objekt auf den Rechner des aktuell
* zugreifenden Objektes. Sonst brich die Migration ab.
* Führe nach 50 Zugriffen ein Reset auf die gesammelten Informationen aus, und
* beginne mit der Überprüfung von vorn.
* Eine Migration soll jedoch nur stattfinden, wenn aktuell keine Migration im
* System durchgeführt wird.
* Mehrfachmigration des zugegriffenen Objektes ist erlaubt.
*/
public class PostMigrationDecidionStrategy extends DefaultDecidionStrategy
{
// legt Startschwellwert 20 für Migrationsüberprüfung fest
public int getStartMigrationDecitionThreshold()
{ return 20; }
// legt Schwellwert 50 für Reset auf die gesammelten Informationen fest
public int getResetThreshold()
{ return 50; }
// erlaubt Mehrfachmigration
public boolean doSingleMigration()
{ return false; }
public void checkMigration(AccessObjectManager accessObjectManager,
String className, int objectID, String objectIP, String accessObjectName,
int accessObjectID, String remoteHostIP)
{
int totalNumberOfAllAccesses = accessObjectManager.getTotalNumberOfAllAccesses();
// Führe nach 50 Zugriffen auf die gesammelten Informationen des Objekts ein Reset aus.
if(totalNumberOfAllAccesses >= getResetThreshold())
accessObjectManager.clearAllAccesses();
// Überprüfe, ob die Anzahl aller Zugriffe auf das Objekt mindestens 20 sind.
if(totalNumberOfAllAccesses >= getStartMigrationDecitionThreshold())
{
// Führe Migration nur durch, wenn derzeit keine Migration im System aktiv ist.
if(!RuntimeEnvironment.localNode.migrationAtSystemActive())
{
int totalNumberOfRemoteAccesses = accessObjectManager.
getTotalNumberOfRemoteAccessesFromNode(remoteHostIP);
int totalNumberOfLocalAccesses = accessObjectManager.
getTotalNumberOfLocalAccesses();
// Ist die Anzahl der entfernten Zugriffe größer als die Anzahl der
// lokalen Zugriffe, dann migriere.
if(totalNumberOfRemoteAccesses > totalNumberOfLocalAccesses)
{
// Ermittle die ID des Zielrechners über dessen IP-Adresse.
int destinationNodeHostID = RuntimeEnvironment.
localNode.getNodeHostIDForHostIP(remoteHostIP);
}
// Überprüfe, ob die ID des Zielrechners nicht die ID des lokalen
// Rechners ist.
if(!RuntimeEnvironment.localNode.getIp().trim().
equals(remoteHostIP.trim()) && destinationNodeHostID != -1)
{
// Migriere zugegriffenes Objekt zum/auf den Rechner der/des
// zugreifenden Objektes.
RuntimeEnvironment.getMigrationStrategy().getObjectTransferer().
migrateObject(className, objectID, objectIP, destinationNodeHostID);
}
// Nachdem die Migration durchgeführt wurde, werden alle gesammelten
// Informationen des migrierten Objektes aus der Registrierung gelöscht.
103

KAPITEL ANHANG E: BEISPIELIMPLEMENTIERUNGEN FÜR
ENTSCHEIDUNGSSTRATEGIEN
}
}
}
}
// Hierdurch wird nicht mehr benötigter Speicher freigegeben.
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration().
removeObjectFromRegistration(className, objectID);
// Migrationsfreigabe: Migration im System als beendet erklären. Dies ist
// notwendig, damit neue Migration im System durchgeführt werden kann.
RuntimeEnvironment.localNode.releaseMigrationAtSystem();
/**
* Entscheidungsstrategie für Replikationsstrategie DELETE des Post-Beispiels
* für Replikation Instanzenanteil- oder Klassenanteil-repräsentierender Objekte.
*
* Strategiebeschreibung:
* Überprüfe nach 20 Zugriffen auf das Objekt, ob die Anzahl der entfernten
* Zugriffe vom Rechner des aktuell zugreifenden Objekt aus größer ist, als
* die Anzahl aller lokalen Zugriffe auf das zugegriffene Objekt. Ist dies
* der Fall, dann repliziere das zugegriffene Objekt auf den Rechner des aktuell
* zugreifenden Objektes. Sonst brich die Replikation ab.
* Führe nach 50 Zugriffen ein Reset auf die gesammelten Informationen aus, und
* beginne mit der Überprüfung von vorn.
* Eine Replikation soll jedoch nur stattfinden, wenn aktuell keine Replikation im
* System durchgeführt wird.
* Wird eine Replikation durchgeführt, dann lösche bei einem Schreibzugriff alle
* Replikate der zugehörigen Replikatgruppe.
*/
public class PostDeleteReplicationDecidionStrategy extends PostMigrationDecidionStrategy
{
// definiert den zu verwendenden Replikationstyp der Strategie
public int getReplicationStrategieType()
{ return REPLICATIONTYPE_DELETE_REPLICAS_BY_WRITEACCESS; }
}
public void checkMigration(AccessObjectManager accessObjectManager,
String className, int objectID, String objectIP, String accessObjectName,
int accessObjectID, String remoteHostIP)
{
... // anlalog zu PostMigrationDecidionStrategy
// Überprüfe, ob die ID des Zielrechners nicht die ID des lokalen
// Rechners ist.
if(!RuntimeEnvironment.localNode.getIp().trim().
equals(remoteHostIP.trim()) && destinationNodeHostID != -1)
{
// Repliziere zugegriffenes Objekt zum/auf den Rechner des zugreifenden
// Objektes.
RuntimeEnvironment.getMigrationStrategy().getObjectTransferer().
replicateObject(className, objectID, objectIP, destinationNodeHostID);
}
}
... // anlalog zu PostMigrationDecidionStrategy
/**
* Entscheidungsstrategie für Replikationsstrategie UPDATE des Post-Beispiels
* für Replikation Instanzenanteil- oder Klassenanteil-repräsentierender Objekte.
*
* Strategiebeschreibung:
* Überprüfe nach 20 Zugriffen auf das Objekt, ob die Anzahl der entfernten
* Zugriffe vom Rechner des aktuell zugreifenden Objekt aus größer ist, als
* die Anzahl aller lokalen Zugriffe auf das zugegriffene Objekt. Ist dies
* der Fall, dann repliziere das zugegriffene Objekt auf den Rechner des aktuell
* zugreifenden Objektes. Sonst brich die Replikation ab.
* Führe nach 50 Zugriffen ein Reset auf die gesammelten Informationen aus, und
* beginne mit der Überprüfung von vorn.
* Eine Replikation soll jedoch nur stattfinden, wenn aktuell keine Replikation im
* System durchgeführt wird.
* Wird eine Replikation durchgeführt, dann führe bei einem Schreibzugriff eine
* Aktualisierung der Replikate der zugehörigen Replikatgruppe durch.
*/
public class PostUpdateReplicationDecidionStrategy extends
PostDeleteReplicationDecidionStrategy
{ // definiert den zu verwendenden Replikationstyp der Strategie
public int getReplicationStrategieType()
{ return REPLICATIONTYPE_UPDATE_REPLICA_BY_WRITEACCESS; }
}
104

ANHANG E: BEISPIELIMPLEMENTIERUNGEN FÜR
ENTSCHEIDUNGSSTRATEGIEN
/**
* Entscheidungsstrategie für Migrationsstrategie des Bibliotheken-Beispiels
* für Migration oder Replikation Instanzenanteil- oder Klassenanteil-repräsentierender
* Objekte.
*
* Strategiebeschreibung:
* Wenn 70% aller entfernten Zugriffe vom Rechner des zugreifenden Objektes größer oder
* gleich der Summe aus Lese- und Nicht-Lese-Oder-Schreibzugriffen entsprechen, dann
* Repliziere das zugegriffene Objekt zum Rechner des zugreifenden Objektes. Ist dies
* nicht der Fall, dann überprüfe, ob die Gesamt- Anzahl der entfernten Zugriffe vom
* Rechner des zugreifenden Objektes aus größer ist, als die Anzahl aller lokalen
* Zugriffe des zugegriffenen Objektes. Ist dies der Fall, dann migriere das zugegriffene
* Objekt zum Rechner des zugreifenden Objektes. Sonst brich die Migration ab.
* Führe nach 100 Zugriffen ein Reset auf die gesammelten Informationen aus, und
* beginne mit der Überprüfung von vorn.
* Eine Migration oder Replikation soll jedoch nur stattfinden, wenn aktuell keine
* Migration oder Replikation im System durchgeführt wird.
* Mehrfachmigration des zugegriffenen Objektes ist erlaubt.
* Wird eine Replikation durchgeführt, dann führe bei einem Schreibzugriff eine
* Aktualisierung der Replikate der zugehörigen Replikatgruppe durch.
*/
public class LibraryMigrationDecidionStrategy extends DefaultDecidionStrategy
{
// legt Startschwellwert 20 für Migrationsüberprüfung fest
public int getStartMigrationDecitionThreshold()
{ return 20; }
// legt Schwellwert 100 für Reset auf die gesammelten Informationen fest
public int getResetThreshold()
{ return 100; }
// erlaubt Mehrfachmigration
public boolean doSingleMigration()
{ return false; }
// legt Replikationstyp bei Replikation fest
public int getReplicationStrategieType()
{ return REPLICATIONTYPE_UPDATE_REPLICAS_BY_WRITEACCESS; }
// legt Replikationsschwellwert 70% fest
// Dass heißt, 70% aller Zugriffe vom Rechner des zugreifenden Objektes
// aus müssen Lesezugriffe oder Nicht-Lese-Oder-Schreibzugriffe sein,
// damit eine Replikation durchgeführt wird.
public int getReplicationThreshold()
{ return 70; }
public void checkMigration(AccessObjectManager accessObjectManager,
String className, int objectID, String objectIP, String accessObjectName,
int accessObjectID, String remoteHostIP)
{
// Anzahl aller Zugriffe auf das zugegriffene Objekt.
int totalNumberOfAllAccesses = accessObjectManager.getTotalNumberOfAllAccesses();
// Anzahl aller Zugriffe vom Rechner des zugreifenden Objektes aus.
int totalNumberOfRemoteAccessesFromAccessObjectNode = accessObjectManager.
getTotalNumberOfRemoteAccessesFromNode(remoteHostIP);
// Anzahl aller Lesezugriffe vom Rechner des zugreifenden Objektes aus.
int totalNumberOfRemoteReadAccessesFromAccessObjectNode = accessObjectManager.
getTotalNumberOfRemoteReadAccessesFromNode(remoteHostIP);
// Anzahl aller Nicht-Lese-Oder-Schreibzugriffe vom Rechner des
// zugreifenden Objektes aus.
int totalNumberOfRemoteNonReadOrWriteAccessesFromAccessObjectNode =
accessObjectManager.getTotalNumberOfRemoteNonReadOrWriteAccessesFromNode(remoteHostIP);
// Führe nach 100 Zugriffen auf die gesammelten Informationen des Objekts ein
// Reset aus.
if(totalNumberOfAllAccesses >= getResetThreshold())
accessObjectManager.clearAllAccesses();
// Überprüfe, ob die Anzahl aller Zugriffe auf das Objekt mindestens 20 sind.
if(totalNumberOfAllAccesses >= getStartMigrationDecitionThreshold())
{
// Prüfe Replikation
if(((totalNumberOfRemoteAccessesFromAccessObjectNode/100)
*getReplicationThreshold())

KAPITEL ANHANG E: BEISPIELIMPLEMENTIERUNGEN FÜR
ENTSCHEIDUNGSSTRATEGIEN
}
}
106
}
{
totalNumberOfRemoteNonReadOrWriteAccessesFromAccessObjectNode))
// Führe Replikation nur durch, wenn derzeit keine Migration oder
// Replikation im System aktiv ist.
if(!RuntimeEnvironment.localNode.migrationAtSystemActive())
{
// Ermittle die ID des Zielrechners über dessen IP-Adresse.
int destinationNodeHostID = RuntimeEnvironment.
localNode.getNodeHostIDForHostIP(remoteHostIP);
}
// Überprüfe, ob die ID des Zielrechners nicht die ID des lokalen
// Rechners ist.
if(!RuntimeEnvironment.localNode.getIp().trim().
equals(remoteHostIP.trim()) && destinationNodeHostID != -1)
{
// Repliziere zugegriffenes Objekt auf den Rechner der/des
// zugreifenden Objekte/Objektes.
RuntimeEnvironment.getMigrationStrategy().getObjectTransferer().
replicateObject(className, objectID, objectIP, destinationNodeHostID);
}
// Migrationsfreigabe: Replikation im System als beendet erklären.
// Dies ist notwendig, damit eine neue Migration oder Replikation
// im System durchgeführt werden kann.
RuntimeEnvironment.localNode.releaseMigrationAtSystem();
}
else // sonst prüfe Migration
{
// Führe Migration nur durch, wenn derzeit keine Migration im System aktiv ist.
if(!RuntimeEnvironment.localNode.migrationAtSystemActive())
{
// Anzahl aller lokale Zugriffe des zugegriffenen Objektes.
int totalNumberOfLocalAccesses = accessObjectManager.
getTotalNumberOfLocalAccesses();
}
}
// Ist die Anzahl der entfernten Zugriffe vom Rechner des Zugreifers
// größer als die Anzahl der lokalen Zugriffe, dann migriere.
if(totalNumberOfRemoteAccessesFromAccessObjectNode >
totalNumberOfLocalAccesses)
{
// Ermittle die ID des Zielrechners über dessen IP-Adresse.
int destinationNodeHostID = RuntimeEnvironment.
localNode.getNodeHostIDForHostIP(remoteHostIP);
// Überprüfe, ob die ID des Zielrechners nicht die ID des lokalen
// Rechners ist.
if(!RuntimeEnvironment.localNode.getIp().trim().
equals(remoteHostIP.trim()) && destinationNodeHostID != -1)
{
// Migriere zugegriffenes Objekt zum auf den Rechner der/des
// zugreifenden Objekte/Objektes.
RuntimeEnvironment.getMigrationStrategy().getObjectTransferer().
migrateObject(className, objectID, objectIP, destinationNodeHostID);
}
}
// Nachdem die Migration durchgeführt wurde, werden alle gesammelten
// Informationen des migrierten Objektes aus der Registrierung
// gelöscht. Hierdurch wird nicht mehr benötigter Speicher freigegeben.
RuntimeEnvironment.getMigrationStrategy().getInformationRegistration().
removeObjectFromRegistration(className, objectID);
// Migrationsfreigabe: Migration im System als beendet erklären.
// Dies ist notwendig, damit neue Migration im System durchgeführt
// werden kann.
RuntimeEnvironment.localNode.releaseMigrationAtSystem();