Dynamische Adaption in heterogenen verteilten eingebetteten ...

5.4 Eine JVM als Baukasten
Von inkrementellen Verfahren spricht man, wenn die Speicherverwaltung beliebig oft unterbrochen
und wieder fortgesetzt werden kann. Dabei wird jedes Mal ein Teil des Speichers durchsucht. Diese
Verfahren können dann im Wechsel mit der normalen Programmausführung abgearbeitet werden und
führen somit zu einer quasi parallelen Speicherbereinigung. Für viele blockierende Verfahren ist es
möglich, eine inkrementelle Version zu erstellen [GLS75, HGB78].
Damit indirekte Verfahren inkrementell durchgeführt werden können, darf sich der Erreichbarkeitsgraph
während der Suche nach verwendeten Objekten nicht verändern. Im Speziellen darf keine
Referenz von einem unbesuchten Objekt in einen bereits abgelaufenen Zweig eingehängt werden. Denn
wenn gleichzeitig alle anderen Referenzen auf das unbesuchte Objekt gelöscht werden, so wird das
Objekt nicht als referenziert erkannt und fälschlicherweise gelöscht.
Um zu verhindern, dass Referenzen in bereits besuchte Objekte eingefügt werden, müssen Speicherzugriffe
während einer inkrementellen Speicherbereinigung mithilfe von sogenannten Barrieren
überwacht werden. Inkrementelle Verfahren sind durch dieses Vorgehen deutlich aufwendiger als
blockierende Verfahren und benötigen insgesamt mehr Ressourcen für einen vollständigen Durchlauf.
Der Vorteil vom inkrementellen Verfahren liegt jedoch auf der Hand: mit ihnen kann man eine bessere
Verfügbarkeit des Systems erreichen.
Durch Austauschen der Speicherbereinigung kann man beispielsweise den schnellen nicht-verschiebenden
Garbage Collector durch einen verschiebenden auswechseln, wenn der Speicher zu
stark fragmentiert ist. Beim Austausch muss man allerdings beachten, dass neben dem Code auch
Datenstrukturen erzeugt oder angepasst werden müssen. Für einen direkten Garbage Collector müssen
zum Beispiel zunächst die Anzahl der Referenzen auf jedes Objekt ermittelt werden.
Ist eine Speicherbereinigung nur selten notwendig, so ist das Auslagern der Speicherbereinigung als
externer Dienst interessant. Verwendet man dazu den Standardmechanismus der Basisschicht, so wird
allerdings jede untersuchte Referenz separat zum Verwalter übertragen. Außerdem setzt das voraus,
dass der Garbage Collector über festgelegte Schnittstellen auf die Objekte zugreift.
Als Optimierung kann man auch den gesamten relevanten Speicherinhalt vor der Speicherbereinigung
zum Verwalterknoten transportieren. Dann kann auch ein Speicherbereinigungsalgorithmus
eingesetzt werden, der die Objektstruktur implizit kennt und direkt auf dem Speicher arbeitet. Bei
verschiebenden oder kopierenden Verfahren muss der Speicher nach der Bereinigung wieder zurücktransportiert
werden. Verändert das Verfahren die Position von aktiven Objekten nicht, so reicht es aus,
die Speicherverwaltung über den frei gegebenen Speicher zu informieren.
..Bei der Verwendung einer nicht-verschiebenden Speicherbereinigung nach dem mark-and-sweep
Verfahren bringt eine Auslagerung den Vorteil mit sich, dass der Knoten während der Speicherbereinigung
nicht angehalten werden muss. Da der Garbage Collector auf einer Kopie des Speicherinhalts
arbeiten kann, verändert sich der Erreichbarkeitsgraph der Objekte nicht. Alle Objekte, die zur Zeit des
Abbildes nicht mehr erreichbar waren, können auch während der Speicherbereinigung nicht erreicht
werden.
Da jedoch während der externen Speicherbereinigung neue Objekte entstehen können, kann nicht
der gesamte Speicher, der nicht erreichbar war, als frei markiert werden. Stattdessen darf man in der
sweep-Phase nur solchen Speicherplatz freigeben, der auch durch Objekte belegt war.
Das externe Ausführen der Speicherbereinigung kann sich speziell für kleine Knoten mit sehr wenig
Speicher und Ressourcen lohnen. Hier muss nur sehr wenig Speicher transportiert und der Aufwand
der Speicherbereinigung muss nicht lokal erbracht werden.
113