| |
– 27 –
mit einer doppelt verketteten Liste um. Während Baker eine Read-Barrier zur Synchro-
nisation von Mutator und Collector vorsieht, vertreten Jones und Lins die Meinung,
dass eine Write-Barrier günstiger ist, da sie bessere Performance bietet [Jo96].
Insgesamt bieten Laut Flood et al. [Fl01] parallele Kollektoren, besonders für große,
speicherintensive Multithreaded-Applikationen, ein großes Potenzial, um erstens das
Ziel zu erreichen, die durch GC verursachten Pausen zu verringern und zweitens auch
den Durchsatz zu erhöhen. Ferner ist zu bemerken, dass einige sogenannten Realzeit-
Algorithmen, Zeitschranken nicht garantieren können, was aber eine Bedingung für
Realzeitanwendungen ist [Jo96]. Trotzdem gibt es immer mehr GC-Algorithmen, die
auch Anforderungen für die Entwicklung von Realzeitapplikation berücksichtigen (z.B.
GC für C++ [Ni93]).
Die zunehmende Vernetzung von Computern und anderen Komponenten führt dazu,
dass die Anzahl der Anwendungen, die verteilt über ein Netzwerk ablaufen, immer
mehr zunimmt. Das Ziel in einem verteilten System ist, dass trotz der Vernetzung und
Interaktion mehrerer autonomer Rechner eine Anwendung transparent für einen Benut-
zer abläuft. Jedoch bedingen zusätzliche Probleme, wie z.B. Race Conditions zwischen
Nachrichten, Duplikate oder verlorene Nachrichten zusätzliche Anforderungen in Bezug
auf Robustheit und Fehlertoleranz, um GC in verteilten Systemen durchführen zu kön-
nen. Neben Algorithmen, die auf einem Mark-Sweep-Verfahren beruhen -
wie der
Mark-Tree Collector von Hudak und Keller (vgl. Kap. 4.2.1) - gibt es auch verschiede-
ne hybride Collectoren, die aus lokalen Tracing- und globalen Reference Counting-
Verfahren bestehen (vgl. Kap. 4.2.2). Durch Kombination der beiden Verfahren lassen
beispielsweise auch zyklische Garbage-Strukturen entdecken.
Mit zunehmender Bedeutung objektorientierter Sprachen gibt es auch Überlegungen,
wie verteilte GC als eine Betriebssystemkomponente umgesetzt bzw. durch Betriebssys-
temkomponenten unterstützt werden kann [Pl91]. Dabei fordern beispielsweise Plain-
fossé und Shapiro, dass der verwendete Algorithmus parallel ablaufen und skalierbar
sein muss und unverlässliche Kommunikation tolerieren sollte.
Abschließend soll bemerkt werden, dass die Distributed Garbage Collection in Java™
(beispielsweise für Anwendungen mit Remote Methode Invocation - RMI) auf einem
Reference Counting-Verfahren basiert, wobei auch das sogenannte Leasing-Konzept,
d.h. das Bewilligen von Ressourcen für einen bestimmten Zeitraum, Anwendung findet
[Kap. 5.2.6, Co01].
|  |
|
| |
|
|
