1.2 Garbage-Collection

Fachbereich Informatik
Integrierte Schaltungen und Systeme
Prof. Dr.-Ing. Sorin Huss
Diplomarbeit
Entwicklung eines Gargbage-Collectors für
rekonfigurierbare Hardwarestrukturen
Felix Madlener
madlener@iss.tu-darmstadt.de
Matr.-Nr.: 948463
Betreuer : Dipl.-Inform. Andreas Kühn
Abgabe : 8.6.2005

Zusicherungen zur Diplomarbeit gemäß §19 Abs. 6 der
Diplomprüfungsordung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter nur mit den
angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus Quellen
entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in
gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 8.6.2005
Felix Madlener

Inhaltsverzeichnis
Abbildungsverzeichnis
v
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Garbage-Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Begriffe und Strukturen 5
2.1 Konfigurationsmöglichkeiten eines FPGA . . . . . . . . . . . . . . . . 5
2.2 Objektorientierte Konzepte . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Strukturierung der Hardware . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Layer 1: Logik-Ebene . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Layer 2: Struktur-Ebene . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Layer 3: Protokolle . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Layer 4: Middleware . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 Layer 5: Applikation . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.6 Layer 6: SW-Engineering . . . . . . . . . . . . . . . . . . . . 12
2.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Vereinfachte Repräsentation eines Programms . . . . . . . . . . . . . . 13
3 Garbage-Collection in Software 17
3.1 Statische Reservierung . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Explizite Reservierung . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Referenzzählung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Mark-Sweep Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Erweiterungen der Mark-Sweep-Collection . . . . . . . . . . . . . . . 21
3.5.1 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2 Nebenläufigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.3 Generational Collection . . . . . . . . . . . . . . . . . . . . . 23

iv
INHALTSVERZEICHNIS
4 Garbage-Collection in Hardware 25
4.1 Einordnung der Garbage-Collection . . . . . . . . . . . . . . . . . . . 26
4.2 Traversierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Nebenläufigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Generational Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Der Algorithmus der Hardware-Garbage-Collection (HW-GC) . . . . . 34
5 Analyse des HW-GC-Algorithmus 39
5.1 Objektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Softwarebasiertes Simulationsmodell . . . . . . . . . . . . . . . . . . . 41
5.3 Qualitative Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.1 Warten auf den nächsten Garbage-Collection-Zyklus . . . . . . 46
5.3.2 Die Traversierung im Mark-Prozess . . . . . . . . . . . . . . . 47
5.3.3 Der Sweep-Prozess . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.4 Funktionalität des HW-GC-Algorithmus . . . . . . . . . . . . . 49
5.4 Quantitative Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.1 Laufzeit der Traversierung . . . . . . . . . . . . . . . . . . . . 50
5.4.2 PageMiss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Häufigkeit der GC-Zyklen . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Zusammenfassung 57
6.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Literaturverzeichnis 59

Abbildungsverzeichnis
1.1 Flexibilität und Effizienz bei verschiedenen Architekturen . . . . . . . . 2
2.1 Abstraktionsebenen der Entwurfsmethodik . . . . . . . . . . . . . . . . 9
2.2 Struktur eines Virtex2 Pro FPGA . . . . . . . . . . . . . . . . . . . . . 10
2.3 Schematischer Aufbau eines Objekts und der Computing Page . . . . . 12
2.4 Programmablauf und Objektgraph . . . . . . . . . . . . . . . . . . . . 15
3.1 Inkorrekter Objektgraph bei nebenläufiger Garbage-Collection . . . . . 23
4.1 Traversierungsreihenfolge eines Objektgraphen mit sequenzieller Traversierung
mit Tiefensuche (a) und nebenläufiger Traversierung (b) . . . 28
4.2 Lokalisierter Bus zur Garbage-Collection . . . . . . . . . . . . . . . . 29
4.3 Ablauf einer Traversierung im HW-GC-Algortihmus . . . . . . . . . . 30
4.4 Algorithmus zur Hardware-Garbage-Collection in VHDL-Pseudocode . 37
5.1 Objektgraphen mit verschiedener Anzahl an ausgehenden Kanten . . . 43
5.2 Minimaler aufspannender Graph . . . . . . . . . . . . . . . . . . . . . 44
5.3 Erreichbare Knoten in Zufallsgraphen . . . . . . . . . . . . . . . . . . 45
5.4 Verschiedene Traversierungen . . . . . . . . . . . . . . . . . . . . . . 52
5.5 Neuer Objektgraph nach löschen der Kante a) zum Zeitpunkt 5 . . . . . 53
5.6 Neuer Objektgraph nach löschen der Kante b) zum Zeitpunkt 4 . . . . . 53

Kapitel 1
Einleitung
1.1 Motivation
Ziel dieser Arbeit ist der Entwurf eines Verfahrens zur automatischen Speicherverwaltung
(Garbage-Collection). Diese Speicherverwaltung ist Teil eines neuartigen, objektorientierten
Entwicklungsansatzes für rekonfigurierbare Hardwarestrukturen.
Herkömmliche Hardware ist statisch aufgebaut. Das Logikdesign und damit auch die
Funktionalität müssen bereits bei der Produktion des entsprechenden Chips vollständig
definiert sein. Die Funktionalität einer solchen Architektur kann dann nicht mehr
geändert werden. Dynamische Strukturen und Programme, wie sie im Bereich der Softwareentwicklung
üblich sind, lassen sich somit nicht direkt in einer effizienten Hardwarestruktur
abbilden.
Üblicherweise können vor allem datenflussintensive, aber in ihrer Funktionalität statische
Programme, von den Vorteilen einer Hardwareimplementierung profitieren. Solche
Vorteile sind beispielsweise eine höhere Ausführungsgeschwindigkeit und ein geringerer
Stromverbrauch. Kontrollflussintensive Algorithmen erfordern hingegen die Flexibilität
eines generischen Prozessors mit darauf ablaufenden Programmen.
Mit der Entwicklung von dynamisch rekonfigurierbaren Hardwarestrukturen, wie zum
Beispiel dem Field Programmable Gate Array (FPGA), ist es erstmals möglich auch
in Hardwareimplementierungen dynamische Strukturen umzusetzen. Die Funktionalität
eines FPGAs wird durch seine Konfiguration festgelegt. Sie kann beliebig modifiziert
werden, indem man das FPGA mit einem vorher generierten Datenstrom rekonfiguriert.
Darüberhinaus bieten FPGAs die Möglichkeit zur partiellen Rekonfiguration. Während
bei einer normalen Rekonfiguration immer der gesamte Chip beeinflusst wird, erlaubt
es die partielle Rekonfiguration, nur einzelne Teile des Logikdesigns im laufenden
Betrieb auszutauschen. Der übrige Chip kann dabei ohne Unterbrechung weiterlaufen.
Wie in Abbildung 1.1 veranschaulicht, sind diese dynamisch rekonfigurierbaren Strukturen
in Bezug auf Flexibilität und Effizienz zwischen den flexiblen, aber ineffizienten

2 KAPITEL 1. EINLEITUNG
Software
Flexibilität
Rekonfigurierbare Hardware
Effizienz
Hardware
Abbildung 1.1: Flexibilität und Effizienz bei verschiedenen Architekturen
Softwareprogrammen und den statischen, aber effizienten Hardwareimplementierungen
angeordnet.
Um diese Architektur sinnvoll einzusetzen, ist neben der Verfügbarkeit der Hardware
auch eine Entwurfsmethodik notwendig, die es ermöglicht, die Vorteile der Plattform
voll auszunutzen und umzusetzen.
Die bisherigen Entwurfsmethodiken für dynamisch rekonfigurierbare Strukturen basieren
auf einer Erweiterung der Werkzeuge und Konzepte, wie sie für klassische Hardware
zum Einsatz kommen. Ihre Ausgangsbasis ist also ein effizienter Entwurfsprozess,
der in Bezug auf die Flexibilität jedoch stark eingeschränkt ist. Mit diesen Werkzeugen
können, aufgrund ihrer völlig anderen konzeptionellen Ausrichtung, die Möglichkeiten
zur Flexibilität nicht zufriedenstellend umgesetzt werden.
Diese Arbeit ist Teil eines Projekts zur Entwicklung einer Entwurfsmethodik, die versucht
Konzepte zur Softwareentwicklung auf dynamisch rekonfigurierbare Strukturen
abzubilden. Der schematischen Einordnung aus Abbildung 1.1 folgend, wird also nicht
mehr ein hardwarenaher Entwurfsansatz um Rekonfigurationsmöglichkeiten erweitert,
sondern Ansätze zur flexiblen Entwicklung von Software werden auf dynamisch und
partiell rekonfigurierbare Strukturen übertragen.
Als besonders geeignet hat sich hierfür der objektorientierte Entwicklungsansatz [1]
erwiesen.

1.2. GARBAGE-COLLECTION 3
1.2 Garbage-Collection
Im Rahmen dieser Diplomarbeit wird untersucht, wie gut sich die Garbage-Collection als
wichtiges Element einer objektorientierten Entwurfsmethodik in dynamisch rekonfigurierbare
Hardwarestrukturen übertragen lässt. Unter Garbage-Collection versteht man
eine automatische Verwaltung von verfügbaren Hardwareressourcen, die durch Rekonfiguration
die vom Benutzer gewünschte Funktionalität annehmen können. Die Garbage-
Collection soll auf bewährten Konzepten und Algorithmen aus dem Softwareentwurf
basieren und sich in das Gesamtprojekt zur Entwicklung einer objektorientierten Entwurfsmethodik
für Hardware integrieren.
Neben der Analyse allgemeiner Eigenschaften einer Garbage-Collection für Hardware
soll eine konkrete Implementierung auf FPGAs der Firma Xilinx zur Evaluation dienen.
Außerdem wird untersucht, welche allgemeinen Richtlinien und Eigenschaften sich für
die Konvertierung einer Applikation aus Software in eine hardwarenahe Applikation
finden lassen.
1.3 Überblick
In Kapitel 2 wird vorgestellt, wie sich objektorientierte Konzepte in einen hardwarebasierten
Entwurfsansatz übertragen lassen. Es wird auf die Rahmenbedingungen der
Hardware eingegangen und ein Abstraktionsmodell vorgestellt, das in den Entwurfsmethodiken
verwendet wird.
In Kapitel 3 werden die bestehenden Konzepte und Ansätze zur Speicherverwaltung
analysiert. Ein Schwerpunkt dieser Analyse ist der Mark-Sweep-Algorithmus, der sich
als günstigste Ausgangsbasis für eine Garbage-Collection in Hardware erwiesen hat.
In Kapitel 4 wird beschrieben, wie sich die einzelnen Aspekte der Garbage-Collection
in Hardware abbilden lassen. Es wird erläutert, welche Konzepte übernommen werden
können und inwieweit sie abgeändert werden müssen, um eine effiziente und kompakte
Hardwareimplementierung zu gestatten. Die dabei entwickelten Algorithmen werden
vorgestellt und erläutert.
Kapitel 5 analysiert die gewonnen Algorithmen. Es wird ein informeller Beweis für die
Korrektheit angegeben und versucht allgemeine Aussagen und Metriken für die Leistungsfähigkeit
einer Garbage-Collection anzugeben.
Schließlich liefert Kapitel 6 eine kurze Zusammenfassung der Ergebnisse dieser Arbeit
und weist auf offene Fragestellungen und Optimierungspotenziale hin.

4 KAPITEL 1. EINLEITUNG

Kapitel 2
Begriffe und Strukturen
In diesem Kapitel wird die allgemeine Struktur der Hardware vorgestellt, in welcher
die Garbage-Collection eingebettet ist. Es wird erläutert, wie sich die objektorientierten
Konzepte auf diese Plattform abbilden lassen.
Die existierenden, rekonfigurierbaren Strukturen sind nicht auf die speziellen Eigenschaften
solcher Entwicklungsmethodiken ausgelegt. Um ein System sinnvoller Größe
zu realisieren, ist es deshalb nötig, die Gegebenheiten der vorhandenen Hardware optimal
auszunutzen. Die wesentlichen Teile dieser Konzepte beruhen auf den Arbeiten von
Kühn [2].
2.1 Konfigurationsmöglichkeiten eines FPGA
Als dynamisch rekonfigurierbare Plattform kommt das FPGA Virtex2 Pro V2P30 der
Firma Xilinx zum Einsatz. Die Konfiguration dieser FPGAs basiert auf den Methoden
der klassischen Hardwarewicklung, wie sie auch beim Entwurf von integrierten Schaltungen
zum Einsatz kommen. Zunächst erfolgt ein Logikentwurf in einer abstrakten
Hardwarebeschreibungssprache wie VHDL oder Verilog. Durch Simulation lassen sich
diese Beschreibungen auf hoher Abstraktionsebene evaluieren. Mit Hilfe eines Synthesewerkzeugs
wird aus der Hardwarebeschreibung eine logische Netzliste generiert.
Hierzu kam das Programm Synplify Pro 8.0 der Firma Synplicity [7] zum Einsatz. Diese
Netzliste wird mit herstellerspezifischen Entwicklungstools (Xilinx ISE 6.3 [5]) auf
dem FPGA platziert und verdrahtet. Dabei entsteht ein Bitstream-File. Dieser Bitstream
wird auf das FPGA geladen, das somit konfiguriert ist.
Um nur Teile des FPGAs partiell zu konfigurieren, existieren zwei verschiedene Entwurfswege.
Beide basieren auf dem Entwurfsprozess zur Konfiguration des gesamten
FPGAs. Der “Small Bit Manipulation Design Flow” ermöglicht es, einzelne Logikgatter
neu zu konfigurieren. Großflächige Rekonfigurationen oder Änderungen in der
Verdrahtung einzelner Logikblöcke sind damit nicht möglich. Komplexere Änderun-

6 KAPITEL 2. BEGRIFFE UND STRUKTUREN
gen erlaubt der “Module Based Design Flow”. Dabei werden definierbare Bereiche des
FPGAs zu Modulen zusammengefasst, die sich unabhängig voneinander ersetzen lassen.
Da dieser Design Flow es zulässt, die Verdrahtung zu ändern, muss sichergestellt
werden, dass bei der Rekonfiguration nicht Signalkonflikte an der Schnittstelle mit anderen
Modulen auftreten. Ein Beispiel hierfür wäre eine Signalsenke, die bei der Rekonfiguration
durch ein schreibendes Signal ersetzt wird. Es würde zu einem Konflikt
zweier Treiber auf der Leitung kommen, der einen Hardwaredefekt auslösen kann. Um
in jedem Fall die Signalintegrität zu gewährleisten, werden zur Kommunikation zwischen
den Modulen Bus Macros verwendet. Diese Kommunikationsblöcke bilden die
Schnittstelle zwischen zwei Modulen. Sie nutzen Tri-State-Logikressourcen, um die Signalintegrität
zu gewährleisten. Bus Macros sind während der gesamten Laufzeit des
FPGAs konstant. Eine Kommunikation zweier Module ist ausschließlich über Bus Macros
möglich.
Da der “Small Bit Manipulation Design Flow” kein dynamisches Ändern der Verdrahtung
ermöglicht, ist er für eine Entwurfsmethodik mit hoher Flexibilität als Ziel ungeeignet.
Deshalb wurde für diese Arbeit der “Module Based Design Flow” als Ausgangsbasis
gewählt. Darüber hinaus bietet die eingeschränkte und konstante Schnittstelle eine
direkte Analogie zu den Schnittstellen eines Softwareobjektes, wie in Abschnitt 2.2 beschrieben.
Neben dem FPGA kommt außerdem ein Host-System zum Einsatz, das die erforderlichen
Rekonfigurationen durchführt, das FPGA mit Daten beschickt, sowie die Ergebnisse
ausliest. Die Kommunikation mit dem Host-System erfolgt über eine RS-232
Schnittstelle. Die verwendete FPGA-Plattform AlphaData ADM-XPL [6] würde auch
eine Kommunikation über den schnelleren PCI-Bus gestatten. Auf diese Möglichkeit
wurde verzichtet, da die Pins der entsprechenden Datenleitungen physikalisch weit über
das FPGA verteilt liegen. Eine Schnittstellenerweiterung sämtlicher Module wäre notwendig,
um die Leitungen in einem zentralen Kommunikationsmodul zusammenzuführen.
Um auf diese zusätzliche Komplexität innerhalb der rekonfigurierbaren Module zu
verzichten, wird die RS-232 Schnittstelle bevorzugt, die mit zwei Leitungen (Senden
und Empfangen) zur Kommunikation mit dem Host-System auskommt.
2.2 Objektorientierte Konzepte
Ziel des Projektes, in das diese Arbeit eingebunden ist, ist es zu untersuchen, welche
objektorientierten Konzepte sich auf Hardware abbilden lassen und welche Modifikationen
dabei vorzunehmen sind. Betrand Meyer hat insgesamt 15 Regeln und Prinzipien
aufgestellt, die eine objektorientierte Entwicklung kennzeichnen [1]. Die meisten dieser
Regeln kommen erst bei der Entwicklung eines konkreten Programms zum Einsatz. So
sagt etwa die “Few Interfaces”-Regel aus, dass Objekte so wenig wie möglich miteinander
kommunizieren.

2.2. OBJEKTORIENTIERTE KONZEPTE 7
Einige dieser Prinzipien haben auch Einfluss auf die Konzeption der Laufzeitumgebung,
hier also des FPGAs. Insbesondere gilt:
1. Ein objektorientiertes System besteht aus unabhängigen Objekten.
2. Ein Objekt fasst eine Menge von konzeptionell zusammenhängenden Methoden
zusammen. Diese können über definierte Schnittstellen von anderen Objekten aus
aufgerufen werden
3. Die Schnittstellen eines Objektes werden durch eine Klasse beschrieben. Ein Objekt
ist eine konkrete Instanz dieser Klasse.
4. Die Schnittstellen sollen so kompakt und einfach wie möglich sein.
5. Die Modifikation eines Objektes durch externe Prozesse ist ausschließlich über
seine Schnittstellen möglich.
6. Ein Objekt hat keine Kenntnis über den internen Zustand eines anderen Objekts
(Geheimnisprinzip).
7. Die Objekte werden zur Laufzeit bei Bedarf erzeugt. Zu diesem Zeitpunkt wird
auch der Speicher reserviert, den dieses Objekt benötigt.
8. Wenn ein Objekt von keinem anderen Objekt aus mehr erreichbar ist, sind seine
Daten wegen des Geheimnisprinzips nicht mehr zugänglich. Das Objekt kann
gelöscht, sein Speicherplatz wieder freigegeben werden.
Aus diesen Punkten ergibt sich, weshalb der Ansatz der Objektorientierung sich besonders
gut auf rekonfigurierbare Hardwarestrukturen abbilden lässt: Betrachtet man
die rekonfigurierbaren Module als Objekte eines objektorientierten Systems, so lassen
sich diese Punkte weitgehend direkt abbilden. Der modulare Entwurfsprozess fordert
bereits, dass die Kommunikation zwischen den Modulen ausschließlich über definierte
und kompakte Schnittstellen stattfindet, womit Punkt 4 und 5 erfüllt sind. Kommunikation
außerhalb dieser Schnittstellen ist auf dem FPGA aus physikalischen Gründen nicht
möglich, womit das Geheimnisprinzip aus Punkt 6 erfüllt wird. Das Erzeugen neuer
Objekte und das zugehörige Allozieren von Speicher in Software ist identisch mit dem
dynamischen Rekonfigurieren einzelner Module des FPGAs.
Wie in Punkt 8 der Aufzählung beschrieben, kommt es vor, dass Objekte nicht mehr
benötigt werden und der von ihnen verwendete Speicher freigegeben werden kann. Die
Analogie in dem hardwarebasierten Ansatz ist das Freigeben der Logikressourcen eines
Moduls. In der Praxis wird die Freigabe realisiert, indem solche Module in eine
Liste übernommen werden. Die Liste enthält sämtliche Positionen, die bei der nächsten
entsprechenden Anforderung rekonfiguriert werden können.

8 KAPITEL 2. BEGRIFFE UND STRUKTUREN
Um zu erkennen, welche Objekte nicht mehr benötigt und bei Bedarf gelöscht werden
können, ist es notwendig zu überprüfen, welches Objekt welche anderen Objekte erreichen
kann. Diese Informationen unterliegen als Bestandteil eines Objekts auch dem
Geheimnisprinzip, sind also eigentlich nicht frei von außen abzufragen.
Um trotzdem eine Aussage bezüglich freizugebender Objekte treffen zu können, gibt
es zwei verschiedene Ansätze. Die eine Möglichkeit ist es, das Geheimnisprinzip etwas
abzuschwächen. Jedes Objekt erlaubt dann eine Abfrage, welche anderen Objekte
es noch erreichen kann. Dieser Ansatz ist beispielsweise für Systeme üblich, in denen
Objekte manuell gelöscht werden. Die andere Möglichkeit ist es, die Garbage-
Collection auf Systemebene zu implementieren. Als Teil der Laufzeitumgebung, die
erst solche Mechanismen wie das Geheimnisprinzip bereitstellt, lassen sich die nötigen
Daten ermitteln, ohne dass eine Implementierung das Geheimnisprinzip verletzen kann.
Es ist üblich, das Erkennen von Objekten, die nicht mehr benötigt werden, zu automatisieren.
Diese Mechanismen zur automatischen Speicherverwaltung werden als
Garbage-Collection bezeichnet. Diese Arbeit konzentriert sich auf die Entwicklung einer
Garbage-Collection auf Systemebene. Die Vorteile gegenüber einer Implementierung
auf Anwendungsebene sind zum einen die bessere Effizienz und zum anderen eine
einfache Umgebung für den Entwickler, für den dieser Prozess transparent abläuft.
2.3 Strukturierung der Hardware
Um eine elegante Übertragung der Softwarekonzepte zu gestatten, bietet es sich an,
auf dem FPGA mehrere aufeinander aufbauende Abstraktionsebenen zu definieren, wie
sie in Abbildung 2.1 aufgeführt sind. In den unteren hardwarenahen Ebenen werden die
Mechanismen implementiert, die es erlauben auf den oberen Ebenen vollständig von der
Hardware zu abstrahieren. Die Aufgaben und Bestandteile der einzelnen Layer werden
im Folgenden kurz erläutert.
2.3.1 Layer 1: Logik-Ebene
Die Logik-Ebene stellt die Hardwareressourcen zur Verfügung. Wie erläutert, ist hier
eine Architektur erforderlich, die eine partielle, dynamische Rekonfiguration der Ressourcen
ermöglicht.
In dieser Arbeit kommt ein FPGA der Firma Xilinx zum Einsatz (V2P30 [3]). Die
Virtex2 Reihe bietet als leistungsfähige Baureihe der Firma Xilinx die nötigen Ressourcen,
um verschiedene Ansätze zu evaluieren. Basiseinheiten der Logikressourcen
auf diesem FPGA sind frei konfigurierbare CLBs (Configurable Logic Block), die aus
vier Eingangssignalen ein Ausgangssignal mit Hilfe einer Boole’schen Wahrheitstabelle
bilden. Für taktsynchrone Designs befindet sich hinter jedem CLB ein FlipFlop, das

2.3. STRUKTURIERUNG DER HARDWARE 9
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
Engineering
Application
Middleware
Protokolle
Structured Hardware
Unstructured Hardware
Abstraktionsgrad
Abbildung 2.1: Abstraktionsebenen der Entwurfsmethodik
optional verwendet werden kann. Die Verbindung der CLBs ist über Verdrahtungsressourcen
realisiert, die sich ebenfalls konfigurieren lassen. Zusätzlich bietet die Virtex-2
Plattform komplexere logische Einheiten an. Dies sind zum Beispiel dedizierte Multiplizierer,
Frequenzvervielfacher und sogar PowerPC-Cores. Auf den Einsatz der komplexeren
Einheiten wird in dieser Arbeit verzichtet, um den vorgestellten Entwurfsansatz so
flexibel wie möglich zu halten. Partielle Rekonfiguration ist erst seit kurzem verfügbar
und nur innerhalb gewisser Randbedingungen möglich [4], auf die im nächsten Layer
eingegangen wird.
2.3.2 Layer 2: Struktur-Ebene
In der Struktur-Ebene werden die Logikressourcen von Layer 1 in passende rekonfigurierbare
Module unterteilt und die Busstruktur zur Kommunikation festgelegt. Die
Randbedingungen der verwendeten Hardwarearchitektur bestimmen dieses Design maßgeblich.
Xilinx-FPGAs besitzen eine rechteckige Struktur von ungefähr 92*160 Elementen
(die genauen Maße unterscheiden sich je nach verwendetem Typ). Zur Orientierung
verwendet Xilinx ein X-Y-Koordinaten-System wie in Abbildung 2.2 dargestellt.
Rekonfigurierbare Module müssen die vollständige Höhe des FPGAs abdecken und besitzen
eine horizontale Breite, die ein Vielfaches von Vier darstellen muss. Ein FPGA
mit 92*160 Elementen besitzt damit maximal 40 rekonfigurierbare Elemente der Größe
92*4 Zellen.
Wie bereits erwähnt, muss die Kommunikation zwischen den rekonfigurierbaren Blöcken
über dedizierte Routingressourcen erfolgen. Um die Signalintegrität an der Schnittstelle
auch während der Rekonfiguration eines Moduls sicherzustellen, müssen zur Kom-

10 KAPITEL 2. BEGRIFFE UND STRUKTUREN
Y
n
rekonf.
Modul
3
rekonf.
Modul
2
rekonf.
Modul
1
rekonf.
Modul
0
Arbiter
X
Abbildung 2.2: Struktur eines Virtex2 Pro FPGA
munikation Bussysteme mit Tri-State-Treibern verwendet werden. Die Anzahl der Tri-
State-Treiber ist eng begrenzt und limitiert die maximal mögliche Schnittstelle zwischen
jeweils zwei nebeneinanderliegenden Modulen.
Deshalb ist zur Kommunikation der Module untereinander ein Bussystem realisiert,
welches gegenüber einer direkten Punkt-zu-Punkt Verbindung aller Module auf Kosten
der Geschwindigkeit mit weniger Verdrahtungsressourcen auskommt. Insgesamt verwendet
die Implementierung einen 40 Bit breiten Datenbus.
Neben den frei konfigurierbaren Logikblöcken ist mit dem Arbiter ein statisches Modul
implementiert. Der Arbiter bildet die Laufzeitumgebung für ein Programm, das in
den Modulen realisiert ist. Er fungiert als Busmaster und bildet das Interface zum Host-
System.
Die aktuelle Implementierung besitzt zur Evaluation 15 frei konfigurierbare Module.

2.3. STRUKTURIERUNG DER HARDWARE 11
2.3.3 Layer 3: Protokolle
Die komplexen Busstrukturen machen fortgeschrittene Protokolle erforderlich, die als
eigene Abstraktionsebene aufgefasst werden. Im Rahmen dieser Protokolle wird jedem
rekonfigurierbaren Modul eine Adresse zugeteilt, die mit ihrer geometrischen Position
auf dem Chip identisch ist. Das Modul 3 liegt also beispielsweise zwischen den Modulen
4 und 5. Module sind von rechts nach links durchnummeriert, der Arbiter besitzt die
Adresse 0. In Abbildung 2.2 sind die Adressen über den einzelnen Spalten angegeben.
Aktuell besitzen die Adressen eine Breite von vier Bit, die ausreicht, bis zu 15 Module
anzusprechen.
Die Kommunikation über den Bus enthält damit immer die Adresse des Zielmoduls.
Dazu wird optional eine Absenderadresse mitgeschickt, um beispielsweise einen Rückgabewert
wieder zurück zu senden. Im Normalfall besitzt ein Objekt mehrere unterschiedliche
Methoden, die von außen zugänglich sind. Alle Methoden eines Objekts
besitzen eine eindeutige Identifikationsnummer (ID), die beim Aufruf ebenfalls übertragen
wird. Schließlich müssen auch noch die Argumente des Prozeduraufrufs übertragen
werden.
Die Adresse des Ziels, sowie die Absenderadresse sind jeweils vier Bit breit. Ebenso
das Signal zur Auswählen der Methode, womit ein Objekt maximal 16 verschiedene
Methoden besitzen kann. Die Argumente sind als 16 Bit breiter Bus realisiert.
Zusammengefasst gilt also, dass bei jeder Kommunikation die Adresse des Zielblocks,
optional eine Absenderadresse, Daten für einen Prozeduraufruf, und die ID der aufgerufenen
Prozedur versendet werden. Zusätzliche Kommunikationsstrukturen für Reset-
Signale und ähnliches sind ebenfalls erforderlich.
Außerdem sind verschiedene weitere Kommunikationsstrukturen implementiert, die
beispielsweise ein globales Reset-Signal zu allen Komponenten leiten. Die Möglichkeit,
eine zusätzliche Leitung für die Garbage-Collection zu verwenden ist gegeben. In
dieser Arbeit werden zwei weitere globale Signale eingeführt, die in Kapitel 4 vorgestellt
werden.
2.3.4 Layer 4: Middleware
Die Kombination aus den rekonfigurierbaren Modulen und den Mechanismen zur Protokollverwaltung
bildet den Middleware-Layer.
Wichtigstes Element der Middleware sind die ComputingPages, die einen Containertyp
für die darin eingebetteten eigentlichen Objekte bilden. Abbildung 2.3 gibt einen
schematischen Überblick über die Einbettung der Objekte. Die ComputingPages bieten
ein abstraktes und vereinfachtes Interface zu den Objekten an. Sie implementieren erforderliche
Verwaltungsmechanismen wie Adressdekodierung für den Bus, und Prozedurdekodierung.
Auch Teile der Garbage-Collection, die als Teil jedes Objekts realisiert
sind, sind auf diesem Layer angesiedelt.

12 KAPITEL 2. BEGRIFFE UND STRUKTUREN
Computing Page
RightIn
LeftOut
Protokoll Decoder
RightOut
LeftIn
Objekt
Adresse : 4 Bit
Funktion 0(Arg:16 Bit)
Funktion 1(Arg:16 Bit)
Funktion 15(Arg:16 Bit)
Abbildung 2.3: Schematischer Aufbau eines Objekts und der Computing Page
Darüber hinaus ist der Arbiter ein Teil der Middleware. Er steuert als Busmaster die
Kommunikation zwischen den verschiedenen ComputingPages. Der Arbiter verwaltet
die freien ComputingPages und deaktiviert das Bussystem für die Rekonfiguration einer
ComputingPage. Die systemweiten Komponenten der Garbage-Collection sind ebenfalls
als Teil des Arbiters implementiert. Im Sinne der Kommunikationsprotokolle aus
dem Protokoll-Layer (Layer 3) besitzt der Arbiter die Adresse 0. Geometrisch ist er auf
dem Chip am rechten Rand angeordnet. Eine Rekonfiguration zur Laufzeit ist für den
Arbiter nicht vorgesehen.
2.3.5 Layer 5: Applikation
Die Applikations-Ebene kann auch als Anwendungsebene bezeichnet werden. Sie ist
die Basis zur Entwicklung von Programmen, während die darunterliegenden Layer für
einen Anwender weitgehend transparent und unzugänglich sind. Der Applikations-Layer
belegt den rekonfigurierbaren Block einer ComputingPages mit individuellen Funktionsblöcken.
Jede aktive ComputingPage bildet ein Objekt einer Klasse.
2.3.6 Layer 6: SW-Engineering
Durch Verknüpfung der einzelnen Objekte untereinander entstehen vollständige Threads
und Programme. Die Verknüpfung der Objekte untereinander folgt dabei dem objektorientierten
Paradigma der Modularisierung. Das heißt, die Objekte können einzig über
Prozeduraufrufe auf andere Objekte zugreifen. Dazu muss das aufrufende Objekt die
Adresse des Zielobjektes kennen. Ein Objekt kann durch Aufrufen eines Konstruktors

2.4. BEISPIEL 13
die Anzahl der Objekte im Gesamtsystem erhöhen. Zum Start eines Programms wird ein
initiales Objekt vom Host-System aus erstellt. Diese Objekte werden als Wurzelknoten
bezeichnet und leben während der gesamten Programmausführung. Es ist ohne weiteres
möglich mehrere Wurzelknoten und damit mehrere Threads oder Programme parallel
auf dem FPGA ablaufen zu lassen.
2.4 Beispiel
Die Struktur des Anwendungessystems soll an einem Beispiel verdeutlicht werden. Abbildung
2.4 zeigt das Programmablaufdiagramm für folgendes Codesegment:
c l a s s a : Root {
. . .
Math m = new Math ( ) ;
m. run ( ) ;
P r i n t p = new P r i n t ( ) ;
p . p r i n t (m) ;
}
c l a s s S q r t {
i n t run ( i n t Op1 ) {
return s q r t ( Op1 ) ;
}
c l a s s Math {
void run ( ) {
S q r t s = new S q r t ( ) ;
r e s = s . g e t S q r t ( 3 . 1 4 1 ) ;
s=NULL;
return ( ) ;
}
}
c l a s s P r i n t {
p r i n t ( C l a s s a ) {
. . .
}
}
Das Beispiel beginnt während der Ausführung von Objekt “a” der Klasse “Root”.
Man beachte, dass die Freigabe des Objektes “s” der Klasse “Sqrt” zu keinem vorher
festgelegten Zeitpunkt erfolgt. Der Zeitpunkt wird durch die nächste, der Zuweisung
“s = NULL” folgende, Aktivierung der Garbage-Collection bestimmt. Sobald mit
“s = NULL” die Referenz auf das Objekt der Klasse “Sqrt” überschrieben wurde,
ist dieses nicht mehr erreichbar und kann freigegeben werden.
2.5 Vereinfachte Repräsentation eines Programms
Für die Garbage-Collection ist die Verknüpfung zwischen den Objekten von besonderer
Bedeutung, weil sie angibt, welche Objekte nicht mehr erreichbar sind und somit freigegeben
werden können. Zwei Objekte sind dann miteinander verknüpft, wenn ein Objekt
auf die Methoden eines anderen Objektes zugreifen kann. Hinreichende Bedingung für
die Verknüpfung ist es, wenn ein Objekt A die Adresse eines anderen Objektes B kennt.
Für eine Untersuchung der Eigenschaften eines Garbage-Collection-Algorithmus bietet
es sich an, vom gegebenen Programm zu einem gerichteten Objektgraphen zu abstrahieren.
Jeder Knoten des Graphen repräsentiert ein Objekt und die ausgehenden gerichteten
Kanten geben an, welche anderen Objekte von ihm aus über ihre Adressen

14 KAPITEL 2. BEGRIFFE UND STRUKTUREN
erreichbar sind. Der Graph kann über mehrere ausgezeichnete Wurzelknoten verfügen,
die jeweils die Wurzel eines Threads repräsentieren.
Der Objektgraph für das Beispiel aus Abschnitt 2.4 ist in Abbildung 2.4 dargestellt.
Man sieht, dass verschiedene Operationen, wie Konstruktoraufrufe und lokale Variablenzuweisungen
(“s = NULL”) den Objektgraphen verändern.
Der Graph abstrahiert von der Funktionalität der Objekte, die für eine Garbage-Collection
unerheblich ist. Er beschränkt sich auf die Darstellung der Erreichbarkeit der
Objekte. Die Wurzelknoten eines Programms, die im FPGA von extern erstellt werden,
bilden auch die Wurzelknoten des Graphen.
Im allgemeinen Fall können keine weiteren Aussagen bezüglich der Graphenstruktur
gemacht werden. Trotzdem lassen sich einige zusätzliche heuristische Annahmen
treffen, die darauf beruhen, dass Programme üblicherweise nach gewissen Regeln implementiert
werden. In den meisten Systemen existieren langlebige Objekte, in denen
für kurze Zeit temporäre Objekte angelegt werden. Diese temporären Objekte werden
nur im Rahmen einer Operation benötigt und danach wieder gelöscht. Außerdem hat
sich herausgestellt, dass ein Objekt meist mindestens ebensolang existiert, wie weitere
von ihm erstellte Objekte (Kindobjekte).
Dadurch entsteht eine hierarchische Objektstruktur, die einem Baum der Graphentheorie
ähnelt. Die Tiefe eines Knotens, die als die Anzahl der Kanten zwischen einer
Wurzel und dem Knoten definiert ist, korrespondiert mit seiner Lebensdauer. Die Blätter
des Baums besitzen die höchste Tiefe und sind die kurzlebigsten Objekte. Sie werden
als erstes wieder gelöscht.
Trotzdem bleibt die Baumstruktur nur eine näherungsweise Beschreibung für die meisten
Objektgraphen. Referenzen, die diese Baumstruktur zerstören, kommen ebenfalls
vor, sind jedoch gegenüber den regulären Kanten, eher selten. Für die Entwicklung einer
Garbage-Collection ist diese vereinfachte Sicht damit zumeist unzulänglich. Sie eignet
sich jedoch gut für statistische Analysen der Garbage-Collection. Hierzu zählen etwa
Aussagen über die Effizienz oder der Versuch, einen günstigen Zeitpunkt zum Start der
Garbage-Collection zu finden.
Es gibt verschiedene Untersuchungen, die versuchen, zur Optimierung der Garbage-
Collection weitere Aussagen über die Struktur des Graphen zu treffen und von ihnen
zu profitieren. Einige für diese Arbeit relevante Untersuchungen werden in Kapitel 5
vorgestellt.

2.5. VEREINFACHTE REPRÄSENTATION EINES PROGRAMMS 15
Instanzierung
Procedure(Source,Target [,Operands,...])
Dispatcher / Arbiter a : Root m : Math s : Sqrt p : Print
Create(Math)
Constructor(0,m)
a
Return(a,m)
run(a,m)
run(a,m)
m
a
Create(Sqrt)
Constructor(0,s)
Return(m,s)
m
a
getSqrt(m,s,"3.141")
getSqrt(m,s,"3.141")
Return(m,"1.77")
Return(m,"1.77")
Return(a)
Return(a)
m
s
a
Create(Print)
Constructor(0,p)
Return(a,p)
m
s
a
print(a,p,"1.77")
print(a,p,"1.77")
m
a
p
Abbildung 2.4: Programmablauf und Objektgraph

16 KAPITEL 2. BEGRIFFE UND STRUKTUREN

Kapitel 3
Garbage-Collection in Software
Mit dem Begriff Garbage-Collection (GC) bezeichnet man die automatische Speicherverwaltung
eines objektorientierten Systems. Aufgabe der GC ist es, Objekte, die nicht
mehr verwendet werden können, zu löschen und ihren Speicherbereich zur Wiederverwendung
freizugeben. Ein Objekt kann dann nicht mehr verwendet werden, wenn es
in anderen Objekte keine Referenzen auf dieses Objekt mehr gibt, es also nicht mehr
erreichbar ist. Meyer [1] bietet einen kurzen Überblick über die Entwicklung der GC
und ihre Verwendung in objektorientierten Systemen.
Man unterscheidet zwischen zwei Prozessen: Der Mutator verändert den Inhalt des
Speichers. Er enthält das eigentliche Programm und sollte idealerweise ohne Unterbrechung
laufen. Der Collector implementiert die Garbage-Collection. Seine Aufgabe ist
es zu gewährleisten, dass der Mutator immer in der Lage ist, ausreichend Speicher zu allozieren.
Der Collector sollte den Mutator so wenig wie möglich behindern, ohne dabei
seine Funktionalität einzubüßen.
Die Funktionalität einer GC lässt sich in zwei Anforderung aufteilen:
Definition 3.0.1 (Korrektheit)
Jedes Objekt, das von der Garbage-Collection gelöscht wird, ist zuvor von keinem anderen
Objekt aus mehr erreichbar.
Definition 3.0.2 (Vollständigkeit)
Alle nicht mehr erreichbaren Objekte werden erkannt und freigegeben.
Die Bedingung der Vollständigkeit wird oft zugunsten einer effizienteren GC-Implementierung
abgeschwächt. Mögliche Neuformulierungen der Vollständigkeit fordern
dann, dass jedes nicht erreichbare Objekt irgendwann einmal gelöscht wird. Es wird
nicht mehr gefordert, dass dies bereits beim nächsten GC-Lauf stattfindet. Eine andere
Möglichkeit zur Abschwächung ist die Forderung, dass die GC in jedem Schritt ein
garantiertes Minimum an nicht mehr erreichbaren Objekten löscht. Wichtig ist es, die

18 KAPITEL 3. GARBAGE-COLLECTION IN SOFTWARE
Anforderungen des Mutators zum Allozieren neuer Objekte erfüllen zu können, solange
Speicherbereiche existieren, die nicht mit aktiven Objekten belegt sind.
Wie in Kapitel 2 erläutert, lassen sich die ComputingPages als Objekte einer objektorientierten
Entwurfsmethodik interpretieren.
Der Analogie folgend bildet das rekonfigurierbare FPGA den Speicher, in dem diese
Objekte abgelegt sind. Auch die Konzepte der Garbage-Collection lassen sich mit dieser
Analogie auf FPGAs übertragen. Ihre Aufgabe ist es, die verfügbaren rekonfigurierbaren
Ressourcen zu verwalten.
Neben der Korrektheit und Vollständigkeit ist das wesentliche Merkmal eines guten
Algorithmus zur GC, dass das Programm bei seiner Ausführung so kurz wie möglich unterbrochen
wird. Das Instantiieren eines neuen Objektes (die Anforderung eines freien
Speicherbereiches) soll möglichst unterbrechungsfrei stattfinden. Dazu sind verschiedene
Ansätze zur Garbage-Collection entwickelt worden, die im Folgenden kurz vorgestellt
werden. Zusätzlich wird die Relevanz der Ansätze für rekonfigurierbare Hardware
diskutiert, bevor in Kapitel 4 ein Ansatz für eine effiziente Garbage-Collection in rekonfigurierbarer
Hardware entwickelt und in Kapitel 5 genauer untersucht wird.
3.1 Statische Reservierung
Bei der statischen Speicherreservierung gibt es keine eigentliche Garbage-Collection.
Trotzdem soll dieses Prinzip hier der Vollständigkeit halber erwähnt werden. Bei dieser
Art der Speicherverwaltung wird bereits beim Programmstart der gesamte benötigte
Speicher reserviert. Dynamische Programme, bei denen der Speicherbedarf zur Laufzeit
wachsen kann, sind damit nicht möglich. Vorteil dieser Art von Speicherverwaltung
ist ihre Einfachheit: Man benötigt keine Garbage-Collection und kann daher harten
Echtzeit-Anforderungen genügen, die man durch externe Speicherverwaltung nicht
mehr erfüllen kann. Diese Art der Speicherverwaltung entspricht am ehesten dem klassischen
Ansatz zur Entwicklung von Hardwaredesigns und ist häufig in “Embedded
Systems” anzutreffen .
Charakteristika einer statischen Reservierung
• Keine dynamische Speicherreservierung und Freigabe
• Sehr einfach
• Erfüllt harte Echtzeit-Anforderung
• Keine dynamischen Programme möglich
• Analogie zur Klassischer Hardwareentwicklung

3.2. EXPLIZITE RESERVIERUNG 19
3.2 Explizite Reservierung
Bei der expliziten Speicherreservierung werden die Aufgaben der GC vom Programmierer
übernommen. Dieser kann durch Kenntnis des Programmablaufs bestimmen, wann
ein Objekt nicht mehr verwendet wird. Daraufhin gibt er den vorher vom Objekt belegten
Speicher mit einem entsprechenden Befehl explizit frei. Bekanntestes Beispiel für
dieses Konzept ist die Sprache C [8] mit den Befehlen malloc() und free(). In der Hardwareentwicklung
entspricht es am ehesten den bestehenden Ansätzen zur Ausnutzung
von dynamisch rekonfigurierbarer Hardware, bei denen ebenfalls der Entwickler die
Rekonfiguration steuert. Vorteil dieser Variante ist die gute Kontrolle über das Zeitverhalten
der Speicherverwaltung. Ein wesentlicher Nachteil ist die Komplexität der Softwareentwicklung.
In großen Projekten ist es oft sehr schwer, den Überblick über die
instantiierten Objekte zu behalten. Vergisst der Entwickler Objekte freizugeben, kann
dies zu schwer nachvollziehbaren Fehlern (Memory Leaks) führen, die ein typisches
Problem vieler Anwendungen bilden, die diese Art der Speicherverwaltung nutzen.
Charakteristika einer expliziten Reservierung
• Beispiel: “free” und “malloc” aus C
• Einfach zu implementieren
• Teilweise deterministisches Timing (in kritischen Teilen kein “free” verwenden)
• Analogie zur normalen Hardware-Rekonfiguration
3.3 Referenzzählung
Die Referenzzählung [9] war der erste automatische Ansatz zur Garbage-Collection. Zu
jedem Objekt wird ein Zähler mitgeführt, der angibt, wieviele Referenzen noch auf dieses
Objekt verweisen. Wenn der Zähler auf Null geht, gibt es keine Referenzen mehr
und das Objekt kann gelöscht werden. Um den Referenzzähler aktuell zu halten, ist
es erforderlich, bei jeder Zuweisung einer Referenz (oder auch deren Löschen) den
Referenzzähler zu inkrementieren und dekrementieren. Damit ist dieser Ansatz relativ
zeitaufwändig. Vorteil des Ansatzes ist, dass sich der Mehraufwand gleichmäßig
über das Programm verteilt und die Latenz einer Operation gut einschätzbar ist. Der
Ansatz ermöglicht also die Einhaltung von weichen Echtzeitbedingungen. Als wesentlicher
Nachteil bleibt zu erwähnen, dass die Referenzzählung nicht in der Lage ist eine
zyklisch verkettete Liste korrekt als Garbage zu erkennen, weil alle diese Objekte noch
einen Referenzähler > 0 besitzen.

20 KAPITEL 3. GARBAGE-COLLECTION IN SOFTWARE
Charakteristika der Referenzzählung
• Einfacher Ansatz
• Kann keine Zyklen erkennen
• Bei jeder Zuweisung ändert sich die Referenz (Häufiger Aufruf)
• Weiche Echtzeitbedingungen
3.4 Mark-Sweep Collection
Das Verfahren der Mark-Sweep-Collection ist heute das am häufigsten verwendete Verfahren
zur automatisierten Garbage-Collection. Der Begriff Mark-Sweep-Collection wird
in viele Arbeiten synonym mit dem Begriff Garbage-Collection verwendet.
Bei diesem Verfahren arbeitet der Collector-Prozess in zwei Phasen: In der ersten Phase
(Mark) werden ausgehend von der Wurzel alle erreichbaren Knoten (die Objekte)
markiert. In der zweiten Phase wird der gesamte Speicher einmal linear durchlaufen
(Sweep). Objekte, die nach diesen beiden Phasen nicht als erreichbar markiert sind,
werden wieder freigegeben.
Gegenüber der Referenzzählung gibt es bei diesem Verfahren keine Probleme mit isolierten
Zyklen, weil sie ausgehend von der Wurzel aus nicht erreichbar sind und somit
während der Mark-Phase auch nicht markiert werden.
Das Verfahren ermöglicht es, ausgehend von einem beliebigen Knoten, kleinere Teilbäume
zu traversieren. Damit kann man ohne den Aufwand einer vollständigen Traversierung
nicht mehr erreichbare Objekte finden und freigeben. Diese Idee ist unter dem
Begriff Generational Collection bekannt und wird in Kapitel 3.5.3 näher erläutert.
Hauptnachteil der Mark-Sweep-Collection ist ihr schlechtes Echtzeitverhalten. Sie erfordert
eine vollständige Traversierung des Objekt-Graphen im Mark-Prozess und eine
lineare Traversierung des kompletten Speichers im Sweep-Prozess für einen Collector-
Aufruf. Dadurch kann es zu starken Verzögerungen im Ablauf des Mutators kommen.
Ein weiterer Nachteil dieser Art von Garbage-Collectionist die Fragmentierung des
Speichers. Durch das Löschen von Objekten inmitten des linear angeordneten Speichers
entstehen Lücken. Fordert die nächste Allozierung mehr Speicher an, als in einer
einzelnen Lücke vorhanden ist, muss die Allozierung verhindert werden, obwohl insgesamt
ausreichend freier Speicher vorhanden wäre. Um die Fragmentierung zu beseitigen
muss der belegte Speicher so weit umsortiert werden, dass ausreichend zusammenhängender
freier Speicher vorhanden ist. Eine effiziente Strategie für die Problematik der
Fragmentierung zu finden, ist eine weitere Aufgabe eines GC-Algorithmus.
In der Praxis hat sich die Mark-Sweep-Collection durchgesetzt. Grund dafür ist, neben
der einfachen Implementierung, die gute Erweiterbarkeit um die Nachteile des Verfahrens
zu vermindern oder zu beseitigen.

3.5. ERWEITERUNGEN DER MARK-SWEEP-COLLECTION 21
Auch für Hardware bietet sich die Mark-Sweep-Collection an. Sie ermöglicht Erweiterungen
und Mechanismen zur Nebenläufigkeit, die sich besonders gut für eine direkte
Abbildung auf die inhärent nebenläufige Hardwareumgebung eignen. Das Problem der
Fragmentierung ist aufgrund der homogenen Struktur der ComputingPages vernachlässigbar
für unsere Implementierung vernachlässigbar.
Charakteristika der Mark-Sweep-Collection
• Auch bekannt als Garbage-Collection
• Idee: Objekte bilden einen Baum, der traversiert wird
• Findet auch isolierte Zyklen
• Fragmentierung des Speichers
• Ungünstiges Echtzeit-Verhalten
• Normalerweise suspendiert der Prozess während dem Mark-Schritt
• Zum nebenläufigen Algorithmus erweiterbar
3.5 Erweiterungen der Mark-Sweep-Collection
Im Folgenden werden die Konzepte der wichtigsten Erweiterungen für die Mark-Sweep-
Collection vorgestellt. Es wird zusätzlich jeweils kurz erwähnt, inwiefern sie für eine
Hardwareimplementierung von Interesse sein könnten.
3.5.1 Fragmentierung
Die Copying Collection [10] ist ein Ansatz, das Problem der Fragmentierung des Speichers
zu beseitigen. Bei dieser Art der Garbage-Collection werden zwei disjunkte, gleich
große Speicherbereiche für das Programm (den Mutator) reserviert. Alle Objekte liegen
gemeinsam in einem der beiden Speicherbereiche, der im Lauf der Programmlaufzeit
fragmentiert. Während des GC-Zyklus werden alle aktiven Objekte in den anderen Bereich
verschoben und dort wieder hintereinander im Speicher abgelegt. Danach wechseln
die beiden Speicherbereiche ihre Funktion und der Speicher wird durch den Mutator
bis zum nächste GC-Lauf wieder fragmentiert.
Für die Hardwareimplementierung ist das Problem der Fragmentierung vernachlässigbar,
da die technischen Rahmenbedingungen nur eine kleine Zahl gleichförmig großer
ComputingPages zulassen.

22 KAPITEL 3. GARBAGE-COLLECTION IN SOFTWARE
3.5.2 Nebenläufigkeit
Eine wichtige Methode, die schlechten Echtzeitverhältnisse der Mark-Sweep-Collection
zu verbessern ist, Mutator und Collector als nebenläufige Prozesse zu realisieren. Im
Idealfall kann der Mutator so ohne Unterbrechungen ablaufen, während der Collector
parallel nicht mehr erreichbare Objekte findet und freigibt. Der Mutator muss nur unterbrochen
werden, wenn der Collector nicht ausreichend schnell freie Objekte finden
kann.
Für eine dedizierte Hardwareimplementierung bietet sich ein solcher Ansatz an, da
man die nebenläufigen Strukturen der Plattform optimal nutzen kann.
Die Implementierung eines nebenläufigen Algorithmus ist sehr komplex. Insbesondere
der Beweis der Korrektheit eines solchen Algorithmus erfordert aufwändige formale
Verifikationsmethoden, wie sie zum Beispiel von Dijkstra [11] angewandt werden.
Es lassen sich jedoch einige gemeinsame Aspekte für eine nebenläufige Garbage-
Collection finden, die ein korrekter Algorithmus aufweisen muss. Huelsbergen [12],
Ben-Ari [13], Doligez [14] und Domani [15] geben einige Beispiele für solche Algorithmen
zusammen mit einem formalen oder semi-formalen Beweis ihrer Korrektheit.
Für einen solchen Beweis muss man über atomare Operationen verfügen, die im Rahmen
des GC-Algorithmus zum Einsatz kommen. Ohne solche Operationen lassen sich
keine Aussagen und Invarianten über die Funktionalität eines nebenläufigen Algorithmus
bilden. Für eine Hardwareimplementierung bietet das synchrone Systemdesign und
das Kommunikationsprotokoll über den Arbiter eine passende Ausgangsbasis für atomare
Operationen der Garbage-Collection.
Neben atomaren Operationen muss man darüber hinaus die Funktionalität des Mutators
während eines aktiven Collector-Zyklus in gewissem Rahmen einschränken. Normalerweise
schränkt man entweder die Möglichkeiten zum Schreiben in den Speicher
(write-barrier) oder das Lesen aus dem Speicher (read-barrier) ein. Ohne diese Einschränkungen
könnte der Mutator durch Änderungen an der Objektstruktur während
des aktiven Mark-Prozess die Korrektheit des Algorithmus verletzen. Abbildung 3.1
illustriert dieses Problem an einem Beispiel. Die Zahlen geben die Reihenfolge der Traversierung
während des Mark-Schrittes an, wobei von a) nach b) im Mutator eine Kante
gelöscht und von b) nach c) eine neue Kante hinzugefügt wird. Der Algorithmus erkennt
den Knoten “X” nicht als aktives Objekt, obwohl es offensichtlich erreichbar ist.
Darüber hinaus bilden diese Barrieren die Basis für formelle Beweise zur Korrektheit
einer nebenläufigen Garbage-Collection.
Ein weiterer Nachteil der nebenläufigen Algorithmen bleibt neben ihrer höheren Komplexität
gegenüber sequenziellen Verfahren, dass man bei ihnen die Vollständigkeit der
Garbage-Collection aufgeben muss. Da der Mutator während der Mark-Traversierung
weiter auf die Objektstruktur Zugriff hat, kann es dazu kommen, dass ein Objekte noch
als erreichbar gekennzeichnet ist, obwohl es noch vor dem Ende der Traversierung durch
den Mutator gelöscht wird. Solche Objekte werden im nächsten GC-Zyklus erkannt.

3.5. ERWEITERUNGEN DER MARK-SWEEP-COLLECTION 23
1
1
1
2 2 5
2
5
3 4
3 4 6
X
a) b) c)
Abbildung 3.1: Inkorrekter Objektgraph bei nebenläufiger Garbage-Collection
Eine Erweiterung der Barrieren, um auch diese Problem-Konstellationen zu vermeiden,
würde wieder direkt zu einem sequenziellen Algorithmus zurückführen.
Üblicherweise nimmt man den Nachteil der nicht mehr erfüllbaren Vollständigkeit in
Kauf, da man in den meisten Szenarien nicht in einem GC-Zyklus sämtlichen freizugebenden
Speicher benötigt, sondern nur ausreichend viel freien Speicher, um bis zum
übernächsten GC-Zyklus neue Objekte allozieren zu können.
3.5.3 Generational Collection
Ein weiterer Ansatz, das schlechte Echtzeit-Verhalten der Mark-Sweep-Collection zu
verbessern, ist die Generational Collection, die zuerst von Lieberman [18] vorgeschlagen
wurde und auch unter dem Begriff Generation Scaveging bekannt ist. Dabei wird
der Objektgraph in verschiedene Objekt-Klassen partitioniert. Die Klassen sind dabei
über die Lebensdauer ihrer Objekte definiert.
Der Mark-Sweep Prozess findet nun innerhalb der einzelnen Partitionen statt, wobei
die Partition mit den kurzlebigeren Objekten entsprechend häufiger aufgeräumt wird
als die der langlebigen Objekte. Dadurch wird erreicht, dass man eine kürzere Zeit für
einen GC-Zyklus benötigt, da die einzelnen Partitionen weniger Objekte als das gesamte
Programm enthalten. Zugleich wird die Wahrscheinlichkeit, ausreichend viele Objekte
freizugeben, um ausreichend freien Speicher zur Verfügung zu haben, nicht zu sehr
verringert, weil man in den häufig traversierten kurzlebigen Objekten auch die meisten
wieder freizugebenden Kandidaten finden wird.
Die Generational Collection erfordert in zwei Punkten einen Mehraufwand des GC-
Algorithmus. Kanten, die im ursprünglichen Objektgraphen zwischen Objekten zweier

24 KAPITEL 3. GARBAGE-COLLECTION IN SOFTWARE
verschiedener Partitionen liegen, müssen während der Traversierung zusätzlich überwacht
werden, um zu verhindern, dass ein Objekt, welches nur aus einer anderen Partition
heraus erreichbar ist, nicht versehentlich freigegeben wird.
Ein zweites und grundlegenderes Problem ist die Vorhersage der Lebensdauer eines
Objektes und damit seine Einordnung in die korrekte Partition von Objekten. In einem
beliebigen Programm ist die Lebensdauer nicht vorhersehbar, weshalb hier Heuristiken
zum Tragen kommen müssen.
Der einfachste Ansatz, die Lebensdauer vorherzusagen, ist die so genannte weak generational
hypothesis [18]. Sie besagt, dass: “Junge Objekte kürzer leben”. Das ermöglicht
einfache Implementierungen, die auch in der Praxis zu guten Ergebnissen führen
[16], [17]. Die Annahme beruht auf der intuitiven Beobachtung, dass in einem typischen
Programm meist eine Gruppe von langlebigen Objekte existiert, die viele kurzlebige
temporäre Objekte erstellen, die nach der Verwendung nicht mehr benötigt werden. Zur
Implementierung werden neue Objekte immer in der kurzlebigen Klasse eingeordnet
und zu den langlebigen Objekten verschoben, sobald sie einen GC-Zyklus überstanden
haben.
Komplexere Heuristiken verwenden noch weitere Informationen, wie zum Beispiel
die Art der Referenz eines Objektes auf ein anderes [19]. Dabei wird ausgenutzt, dass
Referenzen, die auf dem Stack des Programms liegen, meist zu kurzlebigeren Objekten
führen als Referenzen im globalen Speicher.
Charakteristika der Generational-Collection
• Bekannt als “Generation Scaveging”
• Verbessert Echtzeit-Verhalten
• Basiert auf der zukünftigen Lebensdauer der Objekte
• Aufwändige Heuristiken

Kapitel 4
Garbage-Collection in Hardware
In diesem Kapitel wird ein Garbage-Collection-Algorithmus für Hardware (HW-GC)
entworfen und entwickelt. Er eignet sich für eine hardwarebasierte Laufzeitumgebung,
wie sie zum Beispiel in Embedded Systems vorkommen kann. Der Algorithmus basiert
auf den Erkenntnissen, die in softwarebasierten Ansätzen entwickelt und in Kapitel 3
vorgestellt worden sind. Er soll dabei besondere Rücksicht auf die Rahmenbedingungen
der verwendeten Evaluationsplattform auf Basis eines FPGAs der Firma Xilinx nehmen.
Diese Einschränkung durch äußere Rahmenbedingungen ist für die Entwicklung hardwarenaher
Mechanismen typisch und stellt keinen Nachteil für die vorgestellten Methodiken
dar, mit denen die bestehenden Algorithmen auf die Hardware adaptiert werden.
In Kapitel 2 wurde bereits detailliert auf die Rahmenbedingungen der verwendeten
Plattform eingegangen. Wesentlichen Einfluss auf die Entwicklung des Algorithmus haben
die folgenden Punkte:
• Die rekonfigurierbaren Module sind nebeneinander angeordnet.
• Kommunikation zwischen den Modulen erfolgt ausschließlich über ein festgelegtes
Interface, das möglichst kompakt gehalten wird.
• Die Module verwenden ein gemeinsames Bussystem zum Datenaustausch. Das
Kommunikationsprotokoll sieht vor, dass sämtliche Kommunikation über den zentralen
Arbiter läuft.
Diese Arbeit konzentriert sich auf die Mark-Sweep Ansätze (siehe Kapitel 3.4). Hauptgrund
für diese Entscheidung ist die Tauglichkeit der Mark-Sweep Garbage-Collection
für eine Erweiterung zur Nebenläufigkeit. Selbst entworfene Hardware bietet ohnehin
Nebenläufigkeit, so dass dieser Ansatz eine einfache und effiziente Implementierung
eines nebenläufigen Garbage-Collection-Algorithmus verspricht. Des weiteren ist
die Kommunikation zwischen einzelnen Objekten verhältnismäßig teuer. Ein Ansatz,
der auf Reference-Counting (Abschnitt 3.3) basiert, erfordert eine Aktualisierung der

26 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
Referenz-Zähler bei jeder Zuweisung. Er wird durch die Kommunikation deutlich mehr
beeinflusst als ein Mark-Sweep Ansatz, der nur zu wenigen Zeitpunkten aktiviert werden
muss, um wieder Objekte freizugeben.
4.1 Einordnung der Garbage-Collection
Eine weitere grundlegende Entscheidung ist die Einordnung der Garbage Collection in
das Schichtenmodell aus Kapitel 2. Wie dort erläutert, lässt sich ein GC-Mechanismus
entweder als Teil der Laufzeitumgebung in der Middleware, oder aber auf Anwendungsebene
im Applikations-Layer implementieren.
Wenn die Garbage-Collection auf Anwendungsebene realisiert wird, lässt sie sich innerhalb
einer ComputingPage als normales Objekt realisieren. Als Mark-Sweep-Algorithmus
benötigt die Garbage-Collection für jedes Objekt Zugriff auf deren Liste aller
erreichbaren Objekte. Auf Anwendungsebene erfolgt das Auslesen dieser Liste über
öffentlichen Methoden, die sämtliche Objekte implementieren müssen. Um den dabei
entstehenden, erheblichen Kommunikationsaufwand zu vermeiden, ist die Garbage-
Collection als Teil der Laufzeitumgebung realisiert. Sie verfügt über zusätzliche, eigene
Kommunikationsmöglichkeiten (Drähte).
Die Mechanismen zur Speicherverwaltung werden als Teil des Arbiters implementiert,
der wiederum als Teil der Middleware parallel zu den frei konfigurierbaren ComputingPages
existiert. Diese Lösung erlaubt es, spezielle Kommunikations- und Traversierungsstrukturen
zu implementieren, welche die Garbage-Collection wesentlich beschleunigen.
Eine zweite Entscheidung betrifft Systeme, die aus mehreren FPGAs bestehen und
damit auch über mehrere Arbiter verfügen. Hier gibt es ebenfalls zwei Möglichkeiten:
• Separate Garbage-Collection pro Chip: Sind die Kommunikationskanäle für die
GC völlig transparent, dann reicht ein GC-Prozess aus. Es müssen Mechanismen
entwickelt werden, ineffiziente Graphen-Traversierungen zu vermeiden. Diese
treten auf, wenn häufiger als nötig Kanten über die Chip-Grenzen hinweg traversiert
werden. Weil diese Kommunikationsart teurer als Traversierungen innerhalb
der Objekte eines Chips ist, sollte sie vermieden werden.
• Alternativ gäbe es die Möglichkeit, eine gemeinsame Garbage-Collection pro
Chip zu realisieren, die mit Hilfe zusätzlicher Logik entsprechend synchronisiert
werden muss.
Mechanismen zur Unterstützung mehrerer Chips werden in dieser Arbeit nicht weiter
betrachtet.

4.2. TRAVERSIERUNG 27
4.2 Traversierung
Kernstück und Hauptunterschied zur Garbage-Collection in Software ist die Traversierung
im Mark-Prozess. Im Gegensatz zu einer klassischen Software Umgebung existieren
in dem FPGA-basierten System weder ein gemeinsamer Speicher noch eine zentrale
Memory-Mangement-Unit (MMU). Dies erfordert die Entwicklung völlig neuer Mechanismen,
um die Referenzen, die in den ComputingPages abgelegt sind, auszulesen
und zur nächsten ComputingPage weiterzuverfolgen.
Ausgangspunkt der Garbage-Collection ist eine zentrale Komponente, die sich in der
hierarchischen Struktur aus Kapitel 2 ähnlich wie der Arbiter einordnen lässt. Aufgabe
dieser Komponente ist es, eine Liste der Wurzelknoten zu halten. Die Wurzelknoten
entstehen, wenn über das Host-Interface ein neuer Prozess gestartet wird. An Ende der
Verarbeitung wird das Ergebnis des Prozesses an das Host-System gesendet und der
Wurzelknoten wieder gelöscht. Darüber hinaus muss die zentrale GC-Komponente entscheiden,
wann ein neuer GC-Zyklus erforderlich ist, weil nicht mehr ausreichend viele
freie ComputingPages zur Verfügung stehen. Um einen neuen GC-Zyklus zu starten,
wird der normale Programmablauf gestoppt, der Mark- und der Sweep-Prozess werden
durchgeführt und die nicht mehr erreichbaren Objekte werden der Liste der verfügbaren
ComputingPages zugeteilt.
Ein erster trivialer Ansatz zur Implementierung der Mark-Sweep-Collection wäre es,
ausgehend von der zentralen Komponente sämtliche Referenzen des ersten Wurzelknotens
auszulesen, lokal abzuspeichern und mit diesen Referenzen den Objektgraph weiter
zu traversieren. Je nach verwendeter Speicherstruktur für die ausgelesenen Referenzen
(Queue oder Stack) entsteht dadurch eine Breiten- oder Tiefensuche [20], die alle von
der Wurzel aus erreichbaren Knoten besucht. In Abbildung 4.1 (linke Seite) wird solch
eine Traversierung für einen einfachen Objektgraphen gezeigt. Für die Funktionalität
der Garbage-Collection ist es zunächst unerheblich, ob eine Breiten- oder Tiefensuche
implementiert wird.
Der grundlegende Nachteil des beschriebenen Ansatzes ist die aufwändige Kommunikation.
Es ist erforderlich, jede Referenz, die in einer aktiven ComputingPage vorkommt,
zur zentralen Garbage-Collection -Komponente zu schicken. Sollte die gerade
gelesene Referenz noch nicht als aktiv markiert sein, so muss in einem weiteren Kommunikationsschritt
das referenzierte Objekt als aktiv markiert, und seine Referenzliste
ausgelesen werden. Bei durchschnittlich n Referenzen pro ComputingPage und m aktiven
ComputingPages auf dem FPGA ist es somit erforderlich, n ∗ m Referenzen zur
zentralen Komponente hin und m Adressen zum Auslesen der nächsten zu traversierenden
Komponente vom Arbiter zu den jeweiligen Objekten zurück zu schicken. Es sind
also insgesamt n ∗ m + m Kommunikationsoperationen nötig.
Unter Berücksichtigung der Randbedingungen, die eine Kommunikation mit dem Arbiter
zu einer teuren Operation machen, ist ein Traversierungsschema wünschenswert,
das mit wesentlich weniger Traversierungen auskommt. Eine effizientere Traversierung

28 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
wird durch verschiedene Ansätze ermöglicht. Durch eine nebenläufige Traversierung
lassen sich mehrere Traversierungsschritte auf einmal durchführen. Im Idealfall lassen
sich sämtliche Referenzen einer ComputingPage in einem einzigen Taktzyklus abarbeiten.
Eine mögliche Traversierung hierfür ist in Abbildung 4.1 (rechte Seite) zu sehen.
Anstelle von sieben Schritten bei der klassischen Tiefensuche (linke Seite) werden hier
nur noch vier Schritte benötigt. Um diese Art der Traversierung zu gewährleisten, ist
ein System notwendig, das es gestattet mit mehreren Modulen parallel zu kommunizieren.
So ist in Schritt drei die zeitgleiche Aktivierung dreier verschiedener Knoten
notwendig. Wegen den beschränkten Kommunikationsressourcen ist diese Forderung
nicht erfüllbar.
1
1
2
6
2
2
3
5
7
3
3 3
4
4
a)
b)
Abbildung 4.1: Traversierungsreihenfolge eines Objektgraphen mit sequenzieller Traversierung
mit Tiefensuche (a) und nebenläufiger Traversierung (b)
In dieser Arbeit ist daher eine Struktur entwickelt worden, die durch Lokalisierung der
Kommunikation eine mehrfache Nutzung des Bussystems innerhalb eines Zeitschritts
erlaubt. Zudem wurde der Algorithmus dezentralisiert. Die Aufgabe der zentralen GC-
Komponente ist es nur noch, die Traversierung in den Wurzelknoten anzustoßen, die
ihrerseits die Traversierung in ihren erreichbaren Knoten selber anstoßen. Ein möglicher
Flaschenhals der Kommunikation im Arbiter ist damit beseitigt.
Die Idee dieses lokalisierten Ansatzes ist es, den Bus innerhalb jeder ComputingPage
mit Hilfe von Registern in beide Richtungen zu isolieren. Anstelle eines einzigen
Bussystems über alle Module hinweg, existieren damit mehrere kleinere Systeme. Jedes
dieser kleineren Systeme kann somit zeitgleich genutzt werden. Eine bessere Auslastung
der Systemressourcen ist nun möglich. Abbildung 4.2 verdeutlicht den Aufbau
der Kommunikationsstrukturen zwischen beliebigen ComputingPages.
Konkret enthält die Implementierung in jeder ComputingPage eine Liste aller Referenzen,
die sie erreichen kann. Der GC besitzt nur die Liste der Wurzel-Knoten. Wenn ein
GC-Zyklus startet, sendet er ein Signal zur Aktivierung an alle Wurzel-Knoten. Diese
werden dadurch aktiviert, sie setzen ein Flag, das sie als besucht markiert und aktivieren
ihrerseits alle ComputingPages aus der lokalen Referenzliste. Zur besseren Ausnutzung

4.2. TRAVERSIERUNG 29
Computing Page (Adresse 3)
Computing Page (Adresse 2)
Computing Page (Adresse 1)
LeftReferences RightReferences LeftReferences RightReferences
LeftReferences
RightReferences
LeftOut
RightIn
LeftOut
RightIn
LeftOut
RightIn
LeftIn
SweepOut
Register
RightOut LeftIn
Register
RightOut
LeftIn
Flag Flag Flag
RightOut
SweepIn SweepOut
SweepIn SweepOut
SweepIn
Register
Abbildung 4.2: Lokalisierter Bus zur Garbage-Collection
der Systemressourcen ist die Referenzliste aufgeteilt in Referenzen, die links, und solche,
die rechts vom aktuellen Knoten liegen. Referenzen, die auf Objekte links von der
aktuellen Position verweisen, brauchen nur über die lokalisierten Datenleitungen zu den
linken Nachbarn gesendet werden. Der Bus in die rechte Richtung ist damit für andere
Signale frei. Trotz einer besseren Ausnutzung der Ressourcen kann es zu Konflikten
kommen, wenn ein Modul gleichzeitig ein von links kommendes Aktivierungssignal
weiterleiten und selber ein Aktivierungssignal nach rechts senden will. Um hierbei Kollisionen
zu vermeiden, dürfen Objekte den Bus nur dann selber verwenden, wenn sie
nicht gerade ein anderes Signal weitersenden.
Abbildung 4.3 zeigt beispielhaft eine Traversierung in der implementierten Datenstruktur.
Jede der fünf nebeneinander angeordneten ComputingPages enthält ein Register
mit Referenzen, die nach links und ein zweites Register für Referenzen, die nach
rechts verweisen. Die Zahlen auf den Kanten entsprechend den Signalen, die zu einem
festgelegten Zeitschritt auf den lokalisierten Bussystemen gesendet werden, die Zeilen
entsprechen den einzelnen Zeitschritten der Traversierung. Zum Zeitschritt t = 4 tritt
in der ComputingPage 3 einer der beschriebenen Buskonflikte auf. Das Modul muss
das von rechts kommende Signal weiterleiten, und kann die eigene Referenz erst im
nächsten Schritt versenden.
Nach abgeschlossener Traversierung ist es im Sweep-Schritt erforderlich, der zentralen
Garbage-Collection-Komponente im Arbiter mitzuteilen, welche ComputingPages bei
der Traversierung aktiviert worden sind. Hierzu dient ein ein Bit breites Schieberegister,
das als Sweep-Leitung bezeichnet wird. Bei der Traversierung wurde in jedem aktivierten
Modul ein entsprechendes Flag gesetzt. Diese Flags sind in dem Schieberegister
hintereinandergeschaltet und werden schrittweise zum Arbiter verschoben. Dieser setzt
daraufhin für jedes nicht gesetzte Flag die korrespondierende ComputingPage auf die
Liste der verfügbaren freien Logikressourcen.
Ein weiteres Problem ist, dass bei der dezentralen Traversierung nicht fest steht, wann

30 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
Zeit
ID 5 ID 4
ID 3
ID 2
ID 1
t=1
1
4
5
1
3
4
5
2
FromArbiter
ID 5
ID 4
ID 3
ID 2
ID 1
t=2
1
4
5
1
3
4
2
5
FromArbiter
ID 5
ID 4
ID 3
ID 2
ID 1
t=3
1
4
5
1
3
4
FromArbiter
activated
ID 5
ID 4
ID 3 ID 2
ID 1
t=4
1
4
5
1
4
FromArbiter
activated
activated
ID 5
ID 4
ID 3 ID 2
ID 1
t=5
1
4
5
1
FromArbiter
activated
activated
activated
ID 5
ID 4
ID 3 ID 2
ID 1
5
t=6
1
FromArbiter
activated
activated
activated
activated
ID 5
ID 4
ID 3 ID 2
ID 1
5
t=7
1
FromArbiter
activated
activated
activated
activated
ID 5
ID 4
ID 3 ID 2
ID 1
t=8
FromArbiter
activated
activated
activated
activated
activated
Abbildung 4.3: Ablauf einer Traversierung im HW-GC-Algortihmus

4.3. FRAGMENTIERUNG 31
sämtliche, lokal ablaufenden Aktivierungen zu Ende sind. Diese Problem wird mit Hilfe
eines "Heartbeat”-Signals gelöst, das zum ressourcensparen ebenfalls auf der Sweep-
Leitung realisiert ist. Eine ComputingPage, die aktiviert wurde und noch nicht zu allen
Einträge aus ihrer Referenzliste ein Aktivierungssignal gesendet hat, schickt auf der
Sweep-Leitung eine ’1’ in Richtung des Arbiters. Weil die Sweepleitung als Schieberegister
realisiert ist, die in jeder ComputingPage ein Register besitzt, erhält man somit
bei n Objekten nach maximal 2 ∗ n Takten eine ’1’ in der zentralen GC-Einheit. Dieser
maximale Fall tritt dann ein, wenn das entfernteste Objekt aktiviert wird. Das Aktivierungssignal
für das Objekt benötigt n Takte um die Register der dazwischenliegenden
Module zu durchlaufen. Noch einmal n Takte sind notwendig, damit das “Heartbeat”-
Signal durch das Schieberegister wieder zurück gelangt. Trifft also innerhalb von 2 ∗ n
Takten keine “Heartbeat”-Signal in der zentralen GC-Komponente ein, so ist die Traversierung
des Mark-Prozess abgeschlossen. Mit Hilfe eines globalen Enable-Signals
wird daraufhin der Sweep-Modus aktiviert, um die Liste der erreichbaren Objekte zu
generieren.
Mögliche Lösungen, die in der Lage wären, in weniger als 2 ∗ n Takten das Ende der
Traversierung zu bestimmen, benötigen weitere Routingressourcen. Aus diesem Grund
wurde auf sie verzichtet.
4.3 Fragmentierung
In einem softwarebasierten, objektorientierten System gibt es zwei Arten, auf die sich
eine Fragmentierung des Speichers auswirken kann (siehe Abschnitt 3.5.1). Wird der
Speicher in zu viele kleine freie Bereiche fragmentiert, so besteht die Möglichkeit, das
eine Anforderung für eine zusammenhängende Menge freien Speicher, wie sie etwa
beim Erstellen eines Objekts vorkommt, von der Speicherverwaltung nicht erfüllt werden
kann. In diesem Fall ist zuerst eine zeitaufwändige Defragmentierung des Speichers
notwendig. Die meisten Garbage-Collection-Algorithmen für Softwaresysteme beinhalten
Mechanismen, um die Fragmentierung des Speichers gering zu halten.
Für den vorgestellten hardwarebasierten Entwicklungsansatz existiert dieser Fall von
Fragmentierung nicht. Ihre Ursache liegt in der Anforderung von Speicherbereichen
verschiedener Größe. Da sämtliche ComputingPages eine konstante Größe besitzen und
entweder vollständig belegt oder vollständig verfügbar sind, kann keine Fragmentierung
auftreten.
Eine zweite Art der Fragmentierung tritt bei einer Softwareimplementierung durch
den Verlust von Lokalität auf. Die Caching-Mechanismen eines modernen Prozessors
erlauben es, auf nah beieinander liegende Speicherbereiche schneller zu zugreifen, als
auf beliebige, weiter entfernt liegende Speicherbereiche. Ist ein Speicher stark fragmentiert,
so liegen auch die Speicherbereiche der Objekte nicht mehr nah beieinander.
Überraschenderweise existiert in der Hardwareimplementierung ein ähnliches Phäno-

32 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
men. Durch die Registerstruktur auf den Signalleitungen benötigt ein Signal länger, um
weiter entfernt liegenden ComputingPages zu erreichen. So ist nur ein Taktzyklus erforderlich,
um ein benachbartes Objekt zu aktivieren. Liegt das zu aktivierende Objekt
hingegen am anderen Rand des FPGAs, so braucht das Signal mehrere Takte, um sämtliche
Register zu durchlaufen. Es existiert also eine bestimmte Zuordnung der Objekte
eines Programms zu den ComputingPages, die eine minimale Traversierungsdauer gewährleistet.
Nutzt man die Möglichkeiten eines FPGAs, ein Modul samt seiner aktuellen
Registerbelegung auszulesen und das Modul an anderer Position wieder auf den Chip
zu laden, so ist man in der Lage die Lokalitätsstruktur zu modifizieren. Bisher existiert
weder ein Algorithmus noch eine Heuristik, um zu bestimmen, wie eine geometrische
Anordnung der ComputingPages aussehen muss, damit die Dauer der Traversierung
minimiert wird. Darüber hinaus benötigt das Verschieben von rekonfigurierbaren Modulen
zu viel Zeit, um praktikabel zu sein.
4.4 Nebenläufigkeit
Zur Implementierung einer nebenläufigen Garbage-Collection gibt es verschiedene Möglichkeiten.
Kernelement aller solcher Algorithmen sind Barrieren, die in Abschnitt 3.5.2
bereits vorgestellt wurden. Zweck dieser Barrieren ist es, gewisse Operationen einzuschränken
um invariante Bedingungen aufzustellen. Diese Invarianzen erlauben eine
nebenläufige Garbage-Collection.
Herkömmliche Ansätze aus Softwareimplementierung bilden zumeist entweder eine
read-barrier, die das Lesen von Daten einschränkt, oder aber eine write-barrier, um die
Aktualisierung von Referenzen währenden einem GC-Lauf einzuschränken.
Zum Entwurf eines sinnvollen Algorithmus für dynamisch rekonfigurierbare Systeme
ist es sinnvoll, eine Liste möglicher Operationen aufzustellen, durch die sich der Objektgraph
ändern kann. Ein Objekt A kann drei verschiedene Arten von Operationen
durchführen, die Einfluss auf den Objektgraph haben:
1. Der Aufruf eines Konstruktors lässt den Arbiter ein weiteres Objekt B instanziieren.
Die Adresse dieses neuen Objekts wird dem aufrufenden Objekt zurückgeliefert.
Der Objektgraph wird um eine gerichtete Kante vom Knoten A zum Knoten
(B) erweitert.
2. Beim Aufrufen einer Methode eines anderen Objekts kann dieses als Rückgabewert
eine Referenz auf ein Objekt C liefern. Auch hier wird der Objektgraph um
eine gerichtete Kante vom Knoten A zum Knoten C erweitert.
3. Durch Operationen innerhalb eines Objektes können Referenzen gelöscht werden
(s = NULL). Hierbei wird die Kante vom Objekt A zum Objekt s entfernt.

4.4. NEBENLÄUFIGKEIT 33
Neue Kanten können durch diesen Fall nicht entstehen, da für das Objekt A keine
Möglichkeit besteht, an weitere neue Referenzen zu kommen.
Das Hinzufügen von Kanten, während in einem nebenläufigen Prozess die Garbage-
Collection aktiv ist, erzeugt eine andere Art von Fehlern, als das Entfernen von Kanten.
Durch das Hinzufügen von Kanten kann es zu Situationen kommen, wie sie in
Abschnitt 3.5.2 in der Abbildung 3.1 dargestellt sind. Diese Fehler sind unbedingt zu
vermeiden.
Für die Entfernung von Kanten kann man den Objektgraphen in zwei Mengen unterteilen;
Knoten die bereits traversiert worden sind und Knoten die noch traversiert werden
müssen. Eine getrennte Betrachtung für den Knoten, der aktuell traversiert wird, ist hier
nicht notwendig. In einem taktsynchronen Design lassen sich der Besuch eines Knotens
und das Löschen einer Referenz (einer Kante im Objektgraph) als atomare Operation
betrachten. Wird eine Kante aus der zweiten Menge gelöscht, so stellt dies kein Problem
da. Die Traversierung wird korrekt erkennen, dass die Kante nicht mehr existiert,
sobald die entsprechenden Postion im Graphen erreicht worden ist. Sämtliche Knoten
aus dem abgearbeiteten Bereich sind bereits als aktiv markiert. Wird hier eine Kante
gelöscht, so besteht die Möglichkeit, dass dadurch ein Objekt unerreichbar wird. Auf
die Funktionalität des Programms hat dies Fall keinen Einfluss, weil das Objekt ja nicht
mehr verwendet wird. Im nächsten GC-Zyklus wird das Objekt dann korrekt als nicht
mehr erreichbar erkannt und verarbeitet. Damit ist es nicht notwendig, lokale Operationen
in einem Objekt, die höchstens Referenzen löschen können, einzuschränken.
Weil nicht mehr alle Objekte innerhalb eines GC-Zyklus zuverlässig als unerreichbar
erkannt werden können, wird die Vollständigkeit aus Definition 3.0.2 zu einer partiellen
Vollständigkeit abgeschwächt.
Definition 4.4.1 (Paritelle Vollständigkeit)
Alle nicht mehr erreichbaren Objekte werden innerhalb von höchstens zwei aufeinander
folgenden GC-Zyklen erkannt und freigegeben.
Die beiden Operationen zum Hinzufügen von Referenzen verwenden zur Kommunikation
das Bus-System und damit den Arbiter. Gibt der Arbiter während eines aktiven
GC-Zyklus also keinem Objekt die Berechtigung den Bus zu verwenden, so kann auch
kein Objekt neue Referenzen erhalten. Diese Deaktivierung des Bus-Systems bildet eine
kombinierte Lese- und Schreibbarriere. Allerdings ist diese Barriere auf globale Kommunikation
(also Kommunikation zwischen verschiedenen Objekten) beschränkt. Der
Ablauf innerhalb einer ComputingPage bleibt davon unbeeinflusst.
Der Sweep-Prozess basiert nur auf den Flags, die während der Traversierung des
Mark-Prozesses gesetzt wurden. Eine Modifikation dieser Register durch normale Methoden
der Objekte ist nicht nötig. Daher ist es möglich, die Barriere im Arbiter bereits
nach dem Mark zu deaktivieren. Sweep-Prozess und normaler Programmablauf können
dann ohne Einschränkungen parallel ablaufen.

34 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
4.5 Generational Collection
Die Generational Collection (siehe Abschnitt 3.5.3) ist eine Methode, um in einem GC-
Zyklus nur eine Partition der aktiven Objekte auf nicht mehr erreichbare Objekte zu
untersuchen. Diese Teilmengen sind so gewählt, dass sie mit höherer Wahrscheinlichkeit
wieder freizugebende Objekte enthalten. Aufgrund der geringen Anzahl an maximal
realisierbaren Objekten auf der aktuellen Plattform und dem hohen Verwaltungsaufwand,
den die Generational Collection mit sich bringt, ist dieses Konzept nicht Bestandteil
einer Garbage-Collection in Hardware.
Ein möglicher Einsatz für die Zukunft wäre der Einsatz von Methoden der Generational
Collection für die Auswahl eines Wurzelknotens zum Starten der Garbage-
Collection. Falls mehrere Threads (und damit mehrere Wurzelknoten) auf dem FPGA
zeitgleich ablaufen, wäre es wünschenswert, die Garbage-Collection auf dem Thread
zu starten, der mit größerer Wahrscheinlichkeit nicht mehr erreichbare Objekte enthält.
Hierzu könnten die entsprechenden Heuristiken verwendet werden. Es bleibt trotzdem
ein nicht unerheblicher Mehraufwand in der Verwaltung der Objekte, um zwischen tatsächlich
nicht mehr erreichbaren Objekten und Objekten der anderen Threads zu unterscheiden.
Aus diesem Grund wurde auf eine entsprechenden Berücksichtigung bei der
Implementierung verzichtet.
4.6 Der Algorithmus der Hardware-Garbage-Collection
(HW-GC)
Im Folgenden werden die Ansätze, die in den letzten Abschnitten entwickelt worden
sind, zu einem konkreten Algorithmus zusammengefasst. Dies sind insbesondere das lokalisierte
Traversierungsschema, sowie die nebenläufige Implementierung von Garbage-
Collection und normalen Programmablauf.
Dieser HW-GC Algorithmus ist speziell auf die Datenstruktur der verwendeten FPGA-
Plattform ausgelegt. Die für die Garbage-Collection relevanten Punkte lauten in kurzen
Stichworten zusammengefasst:
• Jedes Objekt (jede ComputingPage) führt eine Liste mit den Referenzen aller Objekte,
auf die sie zugreifen kann. Diese Liste wird ausschließlich vom Objekt
selber modifiziert. Der Garbage Collector kann sie auslesen.
• Neue Einträge können nur in zwei Fällen in die Referenzliste eingetragen werden:
Erstens, wenn das Objekt ein neues Kind-Objekt erzeugt, oder zweitens, wenn
eine neue Referenz als Ergebnis beim Methodenaufruf eines anderen Objektes
zurückgeliefert wird. Beide Fälle erfordern eine Kommunikation über den Arbiter.

4.6. DER ALGORITHMUS DER HARDWARE-GARBAGE-COLLECTION
(HW-GC) 35
• Ohne Kommunikation mit dem Arbiter kann ein Objekt nur interne Funktionen
abarbeiten. Dabei können Referenzen aus der Referenzliste gelöscht werden (z.B.
s = NULL) aber keine neuen hinzukommen. Für neue Referenzen wäre in jedem
Fall eine Kommunikation (Methodenaufruf oder Instantiierung) über den Arbiter
nötig.
• Es gibt innerhalb eines Prozesses immer nur ein aktives Objekt. Diese Bedingung
ist für die Funktionalität unerheblich, hilft aber bei der späteren Analyse der Leistungsfähigkeit
erheblich weiter. Im Sinne der Garbage-Collection ist die Anzahl
der aktiven Knoten unerheblich. Wesentlich ist nur, dass zur Kommunikation untereinander
ausschließlich der vom Arbiter verwaltete Bus zum Einsatz kommt.
• Wenn man die Kommunikation über den Arbiter deaktiviert, können sich die Referenzlisten
nur noch verkleinern. In dem aufgespannten Objektgraph können also
keine neuen Kanten eingefügt werden. Bei der Traversierung dieses Baumes
mittels eines Mark-Sweep-Algorithmus ist garantiert, dass sämtliche nicht markierten
Objekte gelöscht werden dürfen.
Damit ergibt sich der konkrete Algorithmus HW-GC. Zunächst wird der Algorithmus
informell beschrieben:
Algorithmus 1 Algorithmus HW-GC in einfachem Pseudocode
1: Loop
2: Deaktiviere vor der Mark-Phase die Kommunikation über den Arbiter
3: Aktiviere alle ComputingPages, die in der Liste der Wurzelknoten referenziert
sind
4: Wiederhole
5: Wenn (ein Objekt wurde aktiviert) dann
6: Setze ein internes Flag
7: Sende ein Heartbeat-Signal zum Arbiter
8: Aktiviere alle Objekte, die in der Referenzliste enthalten sind
9: Ende
10: Bis die Traversierung abgeschlossen ist
11: Die Kommunikation über den Arbiter wird wieder freigeschaltet
12: Lese das Sweep-Signal aus und erstelle daraus die Liste der nicht besuchten Module.
Diese können rekonfiguriert werden.
13: Wiederhole
14: Normaler Programmablauf. Es findet keine Speicherbereinigung statt.
15: Bis ein neuer GC-Zyklus erforderlich ist
16: Loop Ende
Dieser Ansatz kommt auch mit mehreren lokalen Threads zurecht. Diese werden durch

36 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE
mehrere Einträge in der Liste der Wurzelknoten realisiert. Eine Erweiterung auf mehrere
zusammengeschaltete FPGAs ist ebenfalls möglich. Durch das abstrakte Adressierungsschema
ist es möglich, die Kommunikation über die Grenzen eines Bausteins hinweg
für den Garbage Collector transparent zu gestalten. In diesem Fall ist das Problem der
Fragementierung zu berücksichtigen. Da die Kommunikation zwischen den verschiedenen
Bausteinen voraussichtlich teurer ist als die lokale Kommunikation, sollten bei der
Garbage-Collection so selten wie möglich Signale zur Aktivierung eines Moduls über
Chip-Grenzen hinweg laufen. Wenn ein Modul über zwei verschiedene Kantenpfade erreichbar
ist, dann sollte der Pfad bevorzugt werden, der lokal verläuft, selbst wenn er
aus mehr Kanten besteht.
Die Beschreibung des Algorithmus in Pseudocode ist zu Gunsten der Verständlichkeit
semantisch uneindeutig. Das gleichzeitige Ablaufen von mehreren nebenläufigen Prozessen
ist mit den üblichen Mitteln zur Beschreibung solcher Algorithmen nur schwer
zu modellieren. Eine exaktere Darstellung des HW-GC-Algorithmus ist in Algorithmus
4.4 dargestellt. Zur Beschreibung wird die Hardwarebeschreibungssprache VHDL
verwendet. Einige komplexe Operationen sind zu informellen Beschreibungen vereinfacht
worden. Der Code besteht aus den zwei wesentlichen Komponenten zur Garbage-
Collection. In der linken Spalte ist die Funktionalität des Arbiters angegeben, die rechte
Spalte enthält die Funktionalität einer einzelnen ComputingPage. Der vorgestellte Algorithmus
kommt mit einem Minimum an Datenleitungen aus.
Die Schnittstelle zwischen zwei ComputingPages besteht jeweils aus zwei unidirektionalen
Leitungen, um Aktivierungssignale in Form von Adressen zu übertragen. In der
aktuellen Implementierung sind die Adressen mit vier Bit Breite implementiert. Es wird
also ein acht Bit breiter Bus zwischen zwei Modulen benötigt. Darüberhinaus benötigt
der Algorithmus ein globales Enable-Signal zum Aktivieren der Garbage-Collection.
Das Sweep-Signal muss seine Daten lediglich ein Richtung des Arbiters weiterleiten.
Es kann also ebenfalls mit einem Bit realisiert werden.
Eine weitere Optimierung der benötigten Systemressourcen ist möglich, weil während
des Mark-Prozesses das normale Bus-System nicht verwendet wird. In dieser Zeit können
die bereits vorhanden Datenstrukturen benutzt werden, um die Module zu aktivieren.
Damit benötigt die Garbage-Collection gegenüber der bisherigen objektorientierten
Hardwareumgebung lediglich zwei weitere Leitungen:
1. Das Enable-Signal der Garbage-Collection
2. Das Sweep-Signal.

4.6. DER ALGORITHMUS DER HARDWARE-GARBAGE-COLLECTION
(HW-GC) 37
e n t i t y A r b i t e r i s
port (
SweepIn : in s t d _ l o g i c ;
EnableGC : out s t d _ l o g i c ;
L e f t O u t : out t A d d r e s s ;
) ;
case GCState i s
−− normal program i s r u n n i n g
−− w a i t u n t i l n e x t GC−Cycle
when I d l e =>
i f ( DelayCounter = MaxTime ) then
GCState
EnableGC

38 KAPITEL 4. GARBAGE-COLLECTION IN HARDWARE

Kapitel 5
Analyse des HW-GC-Algorithmus
In diesem Kapitel sollen die Anforderungen und Möglichkeiten des Algorithmus zur
hardwarebasierten Garbage-Collection (HW-GC) analysiert werden. Insbesondere soll
ein Versuch unternommen werden, die Leistungsfähigkeit des HW-GC-Algorithmus zu
bewerten. Mit dem Mark-Sweep-Algorithmus zur Speicherverwaltung und der Betrachtung
einer ComputingPage als Objekt existieren zwischen der Infrastruktur eines herkömmlichen
Desktop-PCs und der verwendeten FPGA-Plattform einige Gemeinsamkeiten.
Trotzdem erschweren substanzielle Unterschiede den Vergleich der Garbage-
Collection zwischen den beiden Systemen. Insbesondere Verfahren zur Analyse einer
softwarebasierten Speicherverwaltung lassen sich nicht ohne weiteres auf den implementierten
HW-GC abbilden.
Von besonderem Interesse sind vor allem drei Gesichtspunkte:
• Das FPGA erlaubt nur eine eingeschränkte Anzahl von Objekten. Die Plattform
ist nur unzureichend auf die Verwaltung und Instanziierung vieler ComputingPages
zugeschnitten. Eine Analogie hierzu wäre eine Softwareumgebung mit stark
eingeschränktem Speicherplatz. Für solche Plattformen sind GC-Mechanismen
und die zugehörigen Analysen jedoch unüblich.
• Die Hardwareplattform bietet Möglichkeiten zur Implementierung eines voll synchronen
und nebenläufigen Designs. In einer Softwareumgebung sind diese Möglichkeiten
nicht gegeben.
• Die verwendete Datenstruktur zum Speichern der Objekte besteht aus mehreren
ComputingPages die über einen Arbiter miteinander kommunizieren. Die Struktur
unterscheidet sich damit deutlich vom linear angeordneten Speicher eines
Heaps, wie er in einer softwarebasierten Laufzeitumgebung zum Einsatz kommt.

40 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
5.1 Objektstruktur
Die Leistungsfähigkeit von GC-Algorithmen hängt stark von der Struktur des Programms
ab, das zur Laufzeit im System ausgeführt wird. Diese Strukturen können je nach implementiertem
Programm sehr unterschiedlich sein. Das hat auch Auswirkungen auf die
Leistungsfähigkeit der jeweiligen Garbage-Collection. Blackburn [22] hat eine Vielzahl
verschiedener GC-Mechanismen und Programme miteinander verglichen. Seine Untersuchung
kommt zu dem Schluss, dass es keinen optimalen Garbage Collector gibt. Es
lassen sich zwar Klassen von Programmen bestimmen, die besonders stark von einem
bestimmten Algorithmus zur Garbage-Collection profitieren, jedoch existieren ebenso
Programme, für welche die Annahmen und Heuristiken des GC-Algorithmus ungünstig
sind. Dabei handelt es sich nicht um synthetische Programme, die gezielt auf die
Schwachstellen der Garbage-Collection abzielen, sondern um typische, auch in der Praxis
zum Einsatz kommende Programme.
Weil ein Vergleich mit anderen GC-Algorithmen nicht immer praktikabel ist, gibt es
trotz der beschriebenen Probleme einige Ansätze zur Analyse einer einzelnen Garbage-
Collection. So ist es möglich, das System mit Hilfe einer repräsentativen Menge von
Programmen zu testen [21], [22]. Dieser Ansatz ermöglicht eine realistische Aussage
der Leistungsfähigkeit. Hauptproblem der Methodik ist es, eine passende Menge von
Programmen auszuwählen und sicherzustellen, dass ein Großteil aller möglichen Programme
eine große Ähnlichkeit mit einem der Testprogramme bietet. Für den hier vorgestellten
Ansatz ist dieser Lösungsweg wenig erfolgversprechend. Es existieren noch
nicht ausreichend viele verschiedene Programme, um repräsentative Aussagen treffen
zu können. Zudem bietet die geringe Maximalanzahl von Objekten auf der Evaluierungsplattform
nur wenig Spielraum beim Entwurf neuer Programme.
Für diese Arbeit ist der Ansatz der synthetischen Modelle erfolgversprechender. Dabei
wird versucht, ein synthetisches Modell zu entwickeln, das Aussagen bezüglich der
Objektstruktur beliebiger Programme zulässt. Die synthetischen Modelle lassen sich danach
unterteilen, ob sie aus Struktur- oder Verhaltensanalysen gewonnen wurden. Die
Strukturanalysen versuchen aus der Struktur des Speichers Rückschlüsse auf die Lebensdauer
der referenzierten Objekte zu ziehen [23], [24]. Ergebnis dieser Arbeiten
ist beispielsweise, dass die Lebensdauer eines Objektes, das vom Heap aus referenziert
wird, höher ist, als die Lebensdauer eines Objektes, das vom Stack aus referenziert wird.
Im Gegensatz zu Strukturanalyse versuchen die Verhaltensanalysen, mathemathische
Modelle für die Lebensdauer beliebiger Objekte zu finden. Eine Kenntnis der Struktur
erlaubt zwar möglicherweise bessere Modelle, ist aber nicht prinzipiell erforderlich.
Stefanovic hat verschiedene derartige Modelle miteinander verglichen [25]. Seine Arbeit
kommt zu dem Schluss, dass diese Modelle derzeit noch nicht sinnvoll einsetzbar
sind. Die geschätzte Lebensdauer eines Objekts weicht zur Zeit noch zu stark von der
tatsächlichen Lebensdauer ab. Eine Ausnahme bildet die, bereits 1983 von Lieberman
[18] aufgestellte, weak generational hypothesis. Sie besagt, dass jüngere Objekte auch

5.2. SOFTWAREBASIERTES SIMULATIONSMODELL 41
eine kürzere zukünftige Lebenserwartung haben. Diese Hypothese hat sich in der Praxis
vielfach bewährt und bildet die Basis der Generational Collection, die bereits in
Kapitel 3.5.3 vorgestellt wurde.
Alle vorgestellten Modelle der Objektstruktur basieren auf statistischen Annahmen.
Sie sind so ausgerichtet, dass sie für Anwendungen in einer klassischen Laufzeitumgebung
(Desktop-PC) die besten Ergebnisse liefern. Sie lassen sich nur schlecht auf beliebige
Programme übertragen, deren Struktur sich stark von einer Softwareanwendung
unterscheidet. Weil sich die hier verwendete Hardwareumgebung schon in der geringen
Maximalanzahl von Objekten stark von klassischen Laufzeitumgebungen unterscheidet,
sind auch deren Heuristiken nur unzureichend übertragbar.
5.2 Softwarebasiertes Simulationsmodell
Die erste Aufgabe einer Analyse muss die Überprüfung der Funktionalität des entwickelten
Algorithmus sein. Eine erste Evaluation der Algorithmen fand in einem Software-
Simulationsmodell auf Java-Basis [26], [27] statt. Ziel des Modells war es vor allem, zu
überprüfen ob die Nebenläufigkeit der Garbage-Collection zu unzulässigen Objektstrukturen
führen kann. Hierzu ist vor allem eine Simulation der Traversierung des Mark-
Prozesses notwendig.
Durch den Einsatz von mehreren Threads und einer Multi-Prozessor-Plattform lassen
sich die nebenläufigen Aspekte der HW-GC evaluieren.
Um in der Softwaresimulation verlässliche Aussagen treffen zu können, ist die Implementierung
einer passenden Datenstruktur notwendig. Diese Datenstruktur muss das
Verhalten der ComputingPages der Hardwareumgebung möglichst gut annähern.
Im Java-basierten Simulationsmodell wird eine Struktur mit 16 ComputingPages erzeugt.
Diese besitzen eine zufällig generierte Menge von Referenzen aufeinander. In
zwei parallelen Threads wird eine nebenläufige Garbage-Collection simuliert. Ein Thread
simuliert den Mutator, während der andere Thread die Aufgabe des Collectors übernimmt.
Der HW-GC-Algorithmus aus Kapitel 4 deaktiviert während der aktiven Garbage-
Collection die Kommunikation zwischen verschiedenen Modulen. Damit reicht es für
die Simulation aus, wenn der erste Thread lokale Operationen innerhalb einzelner Objekte
simuliert. Er löscht zufällige Referenzen aus beliebigen ComputingPages. Die
Aufgabe des zweiten Thread ist die Simulation des GarbageCollectors. Er führt die Traversierung
durch und markiert erreichbare Objekte. Nach Ende des Traversierung werden
beide Threads gestoppt. Mit Hilfe eines weiteren Algorithmus zur Traversierung
wird überprüft, ob tatsächlich alle erreichbaren Objekte als solche markiert wurden.
Zur Evaluation der Funktionalität ist es notwendig, verschiedene Objektgraphen zu
generieren. Die generierten Objektgraphen müssen ausreichend allgemein sein, um alle
vorkommenden Fälle zur Traversierung abzudecken. Darüberhinaus sollte die generierte
Struktur gewisse Bedingungen erfüllen, die es erlauben, die möglichen Problemfälle des

42 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
Algorithmus aufzuspüren. Für aussagekräftige Tests muss die konkrete Struktur zufällig
generiert werden. Die Java-Umgebung verfährt dabei nach folgendem Algorithmus:
1. Zuerst wird eine einstellbare Anzahl von Knoten zufällig aus den vorhandenen 16
ComputingPages ausgewählt und als Wurzelknoten deklariert.
2. Für jeden Knoten wird eine ebenfalls einstellbare Menge an Referenzen auf andere
Knoten generiert und abgespeichert. Werden in diesem Schritt mehrere gleiche
Referenzen erzeugt, wird die zweite generierte Referenz ignoriert. Für die
Garbage-Collection ist nur relevant, dass der andere Knoten erreichbar ist, nicht
jedoch über wieviele Referenzen. Damit wird zudem erreicht, das die Anzahl der
Referenzen nicht konstant ist, sondern von eins (wenn immer die gleiche Referenze
generiert wurde) bis zu dem eingestellten Maximum an Referenzen (wenn
alle generierten Referenzen unterschiedlich sind) variiert.
Um Garbage-Collection-Algorithmen optimal zu testen, sind die beiden Parameter
“Anzahl der Wurzelknoten” (#W urzelKnoten) und “Anzahl an Referenzen in einem
Knoten” (#KnotenReferenzen) nach zwei Merkmalen optimiert: Der Anzahl der erreichbaren
Knoten und der Anzahl der Kanten im Graph.
Die Anzahl der erreichbaren Knoten sollte möglichst maximal sein. Für die Traversierung
im Mark-Prozess sind nur die erreichbaren Knoten ausschlaggebend, die übrigen
werden in diesem Schritt ignoriert. Ist nur ein einzelner Knoten (der Wurzelknoten) erreichbar,
gibt es keine ausgehenden Kanten. Besteht der Graph aus zwei erreichbaren
Knoten, kann er zwei verschiedene Formen haben. Weil einer der beiden Knoten ein
Wurzelknoten ist und der andere Knoten von der Wurzel aus erreichbar ist, muss eine
Kante von der Wurzel zum zweiten Knoten existieren. Die zwei möglichen Objektgraphen
unterscheiden sich darin, ob auch eine Kante vom zweiten Knoten zur Wurzel
zurückverweist. Die Anzahl der möglichen Objektgraphen lässt sich allgemein berechnen.
In einem Graph mit n Objekten gibt es maximal ∑ n
i=0
n∗(n−1)
2
gerichtete Kanten.
Es ist offensichtlich, dass eine große Anzahl von erreichbaren Knoten auch eine Vielzahl
verschiedener möglicher Kantenkombinationen garantiert. Diese Vielzahl ist in der
Simulation wünschenswert um ein möglichst breites Spektrum an Testfällen abzudecken.
Um die Anzahl von erreichbaren Knoten in einem zufällig generierten Graphen zu
beeinflussen, bietet sich die Modifikation der Anzahl von Referenzen innerhalb eines
Knotens an. Enthält jedes Objekt mehr Referenzen, dann weist der Objektgraph mit
großer Wahrscheinlichkeit viele erreichbare Knoten auf. Abbildung 5.1 veranschaulicht
diesen Sachverhalt für vier Knoten. Während es mit nur einer ausgehenden Kante pro
Knoten eine Vielzahl von Kombinationen gibt, bei der mindestens einer der Knoten
nicht erreichbar ist, so gibt es für zwei ausgehende Kanten nur noch eine einzige Kombination
sämtlicher Kanten, damit ein Objekt unerreichbar bleibt. Besitzt jeder Knoten

5.2. SOFTWAREBASIERTES SIMULATIONSMODELL 43
Eine Kante pro Knoten
Zwei Kanten pro Knoten
Drei Kanten pro Knoten
Eine Kante pro Knoten
Zwei Kanten pro Knoten
Abbildung 5.1: Objektgraphen mit verschiedener Anzahl an ausgehenden Kanten
sogar drei ausgehende Kanten, so gibt es nur noch eine einzige Kombination der Kanten.
Der Graph ist in diesem Fall vollständig; alle Objekte sind erreichbar.
Zur Generierung einer möglichst geeigneten Objektstruktur wird also in einem ersten
Schritt evaluiert, bei welchen Parametern nach der Generierung sämtliche Knoten vom
Wurzelknoten aus erreichbar sind. Diese Bedingung wird von einem breiten Bereich
möglicher Parameter erfüllt.
Um eine maximale Erreichbarkeit aller Knoten zu gewährleisten, wäre es am einfachsten,
einen vollständigen Graphen anzulegen. Ein vollständiger Graph enthält alle Kanten,
die möglich sind. Jeder Knoten in diesem Graphen ist auch erreichbar. Zur Simulation
bietet der vollständige Graph jedoch einen gravierenden Nachteil: Wie man in
Abbildung 5.1 sehen kann, hat das Entfernen einer einzelnen Kante keinen Einfluss auf
die Erreichbarkeit. Für die Evaluation der nebenläufigen Garbage-Collection sind jedoch
insbesondere solche Fälle interessant, bei denen das Löschen einer Kante (durch
den Mutator) die Objektstruktur ändert. Diese Modifikation während eines aktiven GC-
Zyklus zeichnet einen nebenläufigen Mechanismus aus und ist Ziel der Softwareevaluation.

44 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
Ein Graph, in dem das Löschen jeder beliebigen Kante Einfluss auf die Erreichbarkeit
der Objekte hat, ist der minimale aufspannende Graph [20]. Dieser Graph besitzt
für n Knoten eine minimale Anzahl von Kanten, so dass dabei immer noch sämtliche
Knoten erreichbar sind. Hierfür werden n − 1 Kanten benötigt. Ein möglicher minimal
aufspannender Graph für vier Knoten ist in Abbildung 5.2 angegeben.
Abbildung 5.2: Minimaler aufspannender Graph
Der minimal aufspannende Graph entsteht, wenn ein Minimum an Kanten in jedem
Knoten erzeugt werden. Diese Forderung nach möglichst wenig Kanten steht im Gegensatz
zur Forderung nach möglichst vielen Kanten, um die Erreichbarkeit aller Knoten
zu gewährleisten.
Es gilt also durch statistische Messungen in der Simulation festzustellen, welche Parameter
zu Generierung des Objektgraphen zu wählen sind, so dass zwar alle 16 ComputingPages
erreichbar sind, die Anzahl der Kanten im Graphen jedoch so klein wie
möglich ist. Die Anzahl der Kanten dient dabei als heuristisches Maß für die “Minimalität”
des Graphen. Es kann nicht sichergestellt werden, dass das Löschen einer Kante in
einem Graphen mit weniger Kanten tatsächlich häufiger die Objektstruktur ändert, als
dies in einem Graphen mit mehr Kanten der Fall ist. Um eine hinreichend große Menge
verschiedener Objektgraphen zu erstellen, ist diese Näherung jedoch ausreichend.
In Abbildung 5.3 sind die Parameter für die Anzahl der erreichbaren Knoten aufgetragen.
Die vier Kurven geben die Anzahl der Wurzelknoten an, die Ergebnisse sind
jeweils über 50 Messreihen gemittelt. Man sieht, dass sich die Kurven ab zwei Referenzen
kaum noch unterscheiden. Das ist darin begründet, dass in diesem Fall mit weitere
Wurzelknoten mit großer Wahrscheinlichkeit auf einem bereits erreichbaren Knoten
zum Liegen kommen.
Wegen der hohen Ähnlichkeit der einzelnen Kurven beschränken wir uns im weiteren
auf Graphen mit zwei Wurzeln. Eine einzige Wurzel würde zwar ebenfalls ausreichen,
um jedoch die Option zu besitzen, Konzepte auch für mehrere die Realisierung mehrerer
Threads zu überprüfen, fiel die Entscheidung auf einen Graphen mit zwei Wurzelknoten.

5.3. QUALITATIVE BETRACHTUNG 45
ErreichbareKnoten
16
14
12
10
8
6
4
2
0
Eine Wurzel
Zwei Wurzeln
Drei Wurzeln
Vier Wurzeln
0 1 2 3 4 5 6 7
KnotenReferenzen
Abbildung 5.3: Erreichbare Knoten in Zufallsgraphen
5.3 Qualitative Betrachtung
Kernstück einer qualitativen Betrachtung der entwickelten Algorithmen muss eine Untersuchung
ihrer korrekten Funktionalität sein. Diese besteht bei der Garbage-Collection
aus vier verschiedenen Aspekten, die im Zusammenspiel ein funktionierendes System
ausmachen.
Theorem 5.3.1 (Funktionalität der Garbage-Collection)
- Der Algorithmus muss korrekt sein (Siehe Definition 3.0.1).
- Der Algorithmus muss partiell vollständig sein (Siehe Definition 4.4.1).
- Bei Bedarf muss der nächste GC-Zyklus gestartet werden (Anlauf-Garantie).
- Ein GC-Zyklus muss terminieren.
Zusätzlich zu den beiden Begriffen der Korrektheit und partiellen Vollständigkeit werden
also zwei Forderungen bezüglich der Laufzeit der Garbage-Collection gestellt.
Die Anlaufgarantie gewährleistet, dass eine Anwendung solange Speicher allozieren
kann, wie noch welcher verfügbar ist. Ohne diese Forderung wäre ein Implementierung
denkbar, die zwar einen absolut korrekten GC-Mechanismus beinhaltet, ihn jedoch niemals
verwendet. Belegter Speicher wird somit nicht mehr freigegeben.

46 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
Die Terminierung des Algorithmus fordert eine endliche Laufzeit der Garbage-Collection.
Würde der Algorithmus nicht terminieren, könnte man einen Algorithmus entwickeln
der unbegrenzt lange für die Traversierung der Daten benötigt. Obwohl solch ein
Algorithmus durchaus korrekt und vollständig sein könnte, ist er für die Praxis untauglich.
Es wäre wünschenswert, die Gültigkeit der Forderungen 5.3.1 mit Hilfe der Methoden
der formalen Verifikation zu beweisen. Allerdings verwenden solche Verifikationsverfahren
üblicherweise eine funktionale Sprache, um die zu verifizierenden Aussagen zu
formulieren. Um Aussagen bezüglich anderer Sprachen (wie in unserem Fall VHDL)
zu treffen, ist es entweder erforderlich, die Algorithmen noch einmal neu zu formulieren,
oder eine Übersetzung aus der Implementierungssprache in die Verifikationssprache
durchzuführen. Beide Ansätze sind komplex [11] und fehleranfällig, so dass sie den
Rahmen der vorliegenden Arbeit sprengen würden. Deswegen beschränkt sich die folgende
qualitative Analyse des HW-GC-Algorithmus auf einen halb-formellen Beweis.
Die Argumentation ist in den meisten Fällen direkt einsichtig und erfordert keine weiteren
formalen Hilfen.
Der Beweis wird nach den einzelnen Prozessen der Garbage-Collection aufgeteilt. Für
jeden dieser Teile wird gezeigt, dass die Forderungen aus Theorem 5.3.1 nicht verletzt
werden. Diese einzelnen Prozesse der Garbage-Collection sind:
1. Warten auf den nächsten Garbage-Collection-Zyklus
2. Die Traversierung im Mark-Prozess
3. Der Sweep-Prozess
5.3.1 Warten auf den nächsten Garbage-Collection-Zyklus
In dieser Phase ist die Garbage-Collection im Ruhezustand. Es findet der normale Programmablauf
statt. Die einzelnen ComputingPages können über den Arbiter miteinander
kommunizieren.
Je nach Implementierung sind für die Anlauf-Garantie zwei unterschiedliche Situationen
denkbar. Wenn der nächste GC-Zyklus nach endlicher Zeit automatisch wieder
startet, ist diese Forderung trivialerweise erfüllt. In diesem Fall kann sogar von einer
Terminierung dieses Teilschritts gesprochen werden.
Es sind jedoch Implementierungen der Garbage-Collection denkbar, bei denen der
nächste Bereinigungsvorgang erst dann startet, wenn die Anforderung eines weiteren,
freien Speicherbereichs nicht mehr erfüllt werden kann. Ein GC-Zyklus wird also nur
ausgeführt, wenn das Freigeben von nicht mehr benötigtem Speicher unbedingt notwendig
ist, um den weiteren Programmablauf zu gewährleisten.
Beim Ablauf eines Programms, dass nur konstanten Speicher benötigt, wird somit niemals
ein GC-Zyklus gestartet. Eine garantierte Terminierung dieses Schrittes ist damit

5.3. QUALITATIVE BETRACHTUNG 47
nicht mehr gegeben, weshalb die Anlauf-Garantie als ein “verallgemeinerter” Terminierungsbegriff
eingeführt wurde.
Die HW-GC-Implementierung verwendet einen einfachen Zähler, um den nächsten
Garbage-Collection-Zyklus zu aktivieren. Offensichtlich erfüllt dieser Ansatz die Anlauf-
Garantie: Wird freier Speicher angefordert, ohne dass dieser verfügbar ist, so existiert
eine definierte Zeitschranke, innerhalb derer der nächste GC-Zyklus angestoßen wird.
Die Forderungen nach Korrektheit und Vollständigkeit können hier ignoriert werden.
Da der eigentliche Mark-Sweep-Prozess noch nicht eingesetzt hat, lassen sich auch noch
keine Aussagen bezüglich dieser beiden Faktoren treffen. Die Forderung nach Terminierung
bezieht sich ebenfalls nur auf den eigentlichen Mark-Sweep-Vorgang. Sie kann
in diesem Schritt ebenfalls ignoriert werden.
Damit gilt:
Theorem 5.3.2
Die Forderungen aus Theorem 5.3.1 werden beim Warten auf den nächsten GC-Zyklus
nicht verletzt.
5.3.2 Die Traversierung im Mark-Prozess
Der Mark-Prozess erfordert den aufwändigsten Beweis. Das ist im Wesentlichen in der
komplexen Struktur der Traversierung begründet.
Wir beginnen den Beweis der Forderungen aus Theorem 5.3.1 mit dem Nachweis der
Korrektheit. Die Korrektheit fordert, dass ein Objekt nur dann freigegeben wird, wenn
es nicht mehr erreichbar ist. Dazu muss gezeigt werden, dass alle Referenzen, die in
einem Objekt abgelegt sind, tatsächlich dazu genutzt werden, die zugehörigen Module
zu aktivieren. Alle Referenzen sind in zwei Listen abgelegt. Diese Listen werden beide
vollständig der Reihe nach abgearbeitet. Die Adressen der einen Liste werden dabei zu
Modulen mit kleineren, die der anderen zu denen mit größeren Adressen geschickt. Die
Implementierung stellt sicher, dass die Referenzen bereits beim Abspeichern der richtigen
Liste zugeteilt werden. Es bleibt zu zeigen, dass die Einträge aus den Referenzlisten
auch gesendet werden und nicht etwa ein Deadlock oder ähnliches auftritt. Ohne
Beschränkung der Allgemeinheit wird im folgenden der auf dem FPGA von rechts nach
links laufende Bus betrachtet. Liegt am rechten Eingang ein gültiges Signal an, so hat
dieses eine höhere Priorität und wird zuerst an den linken Ausgang angelegt. Um sicher
zu stellen, dass alle eigenen Referenzen gesendet werden, muss also gezeigt werden,
dass es eine obere Schranke für die Anzahl der Adressen am rechten Eingang gibt.
Eine solche Schranke existiert, weil rechts von der betrachtete ComputingPage nur
endlich viele weitere Module liegen, die wiederum nur eine endliche Anzahl von Referenzen
enthalten. Es ist also möglich, die eigenen Referenzen in endlicher Zeit abzuarbeiten.

48 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
Der Beweis der Terminierung ist eng verwandt mit dem Beweis zur Korrektheit. Wie
bereits gezeigt wurde, existieren auf beiden Seiten einer beliebigen ComputingPage nur
endlich viele weitere Module. Deswegen lässt sich eine zeitliche Obergrenze angeben,
nach der alle dort enthaltenen Referenzen, abgearbeitet worden sind. Damit existiert
natürlich auch für die gesamte Plattform eine zeitliche Obergrenze zur Abarbeitung
aller Referenzen aus allen Modulen.
Für die partielle Vollständigkeit ist eine Betrachtung der Nebenläufigkeit erforderlich.
Für den Fall, das die Referenzen während des gesamten Mark-Prozesses konstant sind,
ist diese Forderung offensichtlich erfüllt. Während der Traversierung können Referenzen
gelöscht werden. Falls dabei der Objektgraph nicht geändert wird, gilt offensichtlich
immer noch die Vollständigkeit. Wird ein Objekt durch den Löschvorgang unerreichbar,
so gilt zu unterscheiden: Wurden diese Referenzen noch nicht abgearbeitet, gibt es
keine weiteren Auswirkungen. Der Objektgraph kann betrachtet werden, als wäre die
Referenz schon seit Beginn der Traversierung entfernt. Wird eine Referenz hingegen
erst gelöscht, nachdem sie bereits abgearbeitet wurde, wird sie im aktuellen GC-Zyklus
noch als markiert betrachtet und kann nicht freigegeben werden. Nach Voraussetzung
ist das ehemals referenzierte Objekt jetzt unerreichbar. Es kann zu keinem zukünftigen
Zeitpunkt mehr erreichbar sein und wird deshalb im nächsten GC-Zyklus erkannt und
freigegeben.
Die Forderung der Anlauf-Garantie ist trivial erfüllt, weil im Mark-Prozess die Garbage-Collection
ja bereits angelaufen ist.
Damit gilt:
Theorem 5.3.3
Die Forderungen aus Theorem 5.3.1 werden während der Traversierung im Mark-Prozess
nicht verletzt.
5.3.3 Der Sweep-Prozess
Für den Sweep-Prozess gilt, dass die Anlauf-Garantie und Terminierung offensichtlich
gelten. In diesem Prozess wird ein Shift-Register, dessen Breite identisch mit der Anzahl
der ComputingPages ist, einmal vollständig seriell ausgelesen. Weil die Anzahl der
ComputingPages endlich ist, ist damit auch das Auslesen endlich. Der Prozess terminiert
somit. Da die Garbage-Collection noch immer aktiviert ist, ist die Anlauf-Garantie
mit der gleichen Argumentation wie im Mark-Prozess erfüllt.
Auf die Forderungen der Korrektheit und partiellen Vollständigkeit hat der Sweep-
Prozess keinen Einfluss. In diesem Schritt werden in dem Sweep-Register die Flags
ausgelesen, die während des Mark-Prozesses gesetzt worden sind. Wird eine Null gelesen,
so ist das korrespondiere Objekt bei der Traversierung nicht aktiviert worden. Eine
Eins bedeutet, dass das Objekt vom Wurzelknoten aus über Referenzen erreichbar ist.
Der Sweep-Schritt liest diese Markierungen nur aus, modifiziert sie jedoch nicht. Die

5.4. QUANTITATIVE BETRACHTUNG 49
Forderungen zur Korrektheit und partiellen Vollständigkeit sind also erfüllt, solange sie
zu Beginn des Sweep-Prozess erfüllt waren.
Theorem 5.3.4
Die Forderungen aus Theorem 5.3.1 werden während des Sweep-Prozesses nicht verletzt.
5.3.4 Funktionalität des HW-GC-Algorithmus
Mit den Theoremen 5.3.2, 5.3.3 und 5.3.4 ist damit Theorem 5.3.1 nachgewiesen. Der
implementierte Algorithmus erfüllt also die Aufgaben einer automatischen Speicherverwaltung.
Dieser informelle Beweis trifft nur Aussagen bezüglich der textuellen Spezifikation
des Algorithmus. Ein Beweis, dass die konkrete Implementierung (als VHDL-Code
oder gar als Schaltbild) tatsächlich die Spezifikation erfüllt, würde den Rahmen dieser
Arbeit sprengen.
5.4 Quantitative Betrachtung
Die quantitative Analyse eines Algorithmus versucht Aussagen bezüglich seiner Leistungsfähigkeit
zu treffen. Es wird eine Metrik benötigt, in der solche Aussagen getroffen
werden können. Dabei kann es sich entweder um eine relative Metrik handeln, die vergleichende
Aussagen erlaubt. Die Aussage “Der Algorithmus A ist doppelt so schnell,
wie Algorithmus B” wäre ein Beispiel hierfür. Der Vorteil einer solchen Methodik ist
die Möglichkeit verschiedene Algorithmen ohne die Kenntnis ihrer Arbeitsweise vergleichen
zu können. Es reicht aus, sie als “Black-Box”-System zu betrachten und zu
messen. Allerdings lassen sich solche vergleichende Metriken nicht ohne Weiteres verallgemeinern.
Schon durch die Verwendung einer anderen Hardwareplattform sind neue
Erkenntnisse nicht mehr ohne Weiteres mit den alten Ergebnissen vereinbar.
Günstiger ist die Entwicklung einer allgemeinen Metrik, die von einem konkreten Algorithmus
abstrahiert und Merkmale findet, die für alle Algorithmen einer Klasse bestimmbar
sind. Diese Merkmale lassen sich direkt messen und erlauben auch einen Vergleich
zwischen verschiedenen Untersuchungen. Eine Metrik soll so allgemein gefasst
sein, dass sie vielseitig anwendbar ist. Die Schwierigkeit liegt darin, sinnvolle Metriken
zu finden.
Die bekannteste Metrik ist die Laufzeitmessung. Durch Angabe der Laufzeit in Sekunden
lassen sich beliebige Algorithmen miteinander vergleichen. Um einen präziseren
Vergleich zu ermöglichen, ist es sinnvoll, speziellere Metriken zu entwerfen. So ist
beim Vergleich zweier Sortieralgorithmen nicht nur die gesamte Laufzeit von Interesse.
Ebenso wichtig ist es zu bestimmen, wie viele Speicherzugriffe erforderlich sind und

50 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
wieviel Zeit in der Ein/Ausgabe verbracht wird. Es sind also Metriken notwendig, die
Vergleichsmöglichkeiten zwischen möglichst vielen verschiedenen Implementierungen
bieten, gleichzeitig aber auf die wichtigen Aspekte der Algorithmen eingehen. Im Folgenden
werden solche Metriken für die Garbage-Collection entwickelt. Sie berücksichtigen
insbesondere den Einfluss der Nebenläufigkeit, die sich im Ablauf der Traversierung
und in der gleichzeitigen Ausführung von Mutator und Collector niederschlägt.
5.4.1 Laufzeit der Traversierung
Maßgeblich für die Laufzeit eines vollständigen GC-Zyklus ist die Laufzeit der Traversierung
im Mark-Prozess. Um die Leistungsfähigkeit einer Graphentraversierung zu
beurteilen bietet es sich an, anzugeben, wieviel Verarbeitungsschritte sie erfordert. Dieser
Wert hängt von der Struktur der Knoten und der Struktur der Kanten ab.
Der Sweep-Prozess erfordert eine einmalige lineare Traversierung aller Objekte. Für
n Objekte erfordert er somit n Schritte. Der Aufwand für den Mark-Prozess hängt hingegen
vom Objektgraphen ab. Für n ′ erreichbare Objekte, die im Mittel m Referenzen
auf weitere Objekte enthalten, erfordert ein einfacher sequenzieller Ansatz zur Traversierung
bereits m∗n ′ Schritte. Es ist anzumerken, dass es höchstens so viele erreichbare
Objekte gibt, wie insgesamt vorhanden sind. Es ist also n ′ ≤ n. Trotzdem ist der Mark-
Prozess wegen des Einflusses der Referenzen im Normalfall deutlich aufwändiger.
Metrik 5.4.1 (Laufzeit-Effizienz)
Die Laufzeit eines Algorithmus zur Garbage-Collection wird maßgeblich von der Laufzeit
des Mark-Prozess beeinflusst. Seine Effizienz lässt sich durch die Anzahl der Verarbeitungschritte
angeben, die notwendig sind, um alle erreichbaren Objekte zu besuchen.
Wie bereits erwähnt, wird bei einer sequenziellen Traversierung aller Knoten eine Liste
von Referenzen mitgeführt. In jedem Verarbeitungsschritt muss geprüft werden, ob
eine Referenz aus dieser Liste zu einem Knoten führt, der bisher noch nicht besucht wurde.
Ist das der Fall, werden diese Referenzen in die Liste aufgenommen. Der Algorithmus
erfordert also m Verarbeitungsschritte. Alle Referenzen, die im Graphen erreichbar
sind, müssen abgearbeitet werden.
Satz 5.4.1 (Sequenzielle Traversierung)
Die sequenzielle Traversierung eines Objektgraphen mit m erreichbaren Kanten benötigt
m Verarbeitungsschritte.
Bearbeitet man alle Referenzen eines Knotens gleichzeitigt, so erhält man eine parallele
Traversierung des Objektgraphen. In Abbildung 4.2 ist eine solche illustriert. Man
erkennt, dass in jedem Bearbeitungschritt alle Objekte in einer bestimmten Entfernung
zum Wurzelknoten bearbeitet werden. Die Laufzeit ist also durch den längsten Pfad von

5.4. QUANTITATIVE BETRACHTUNG 51
einem Wurzelknoten zu einem anderen erreichbaren Knoten bestimmt. In einer Worst-
Case-Betrachtung ist die Länge dieses Pfades mit der Menge aller erreichbaren Objekte
n ′ identisch. Dabei sind alle Objekte in einer Reihe angeordnet und enthalten jeweils
die Referenz auf ihren nächsten Nachbarn. Üblicherweise ist der längste Pfad deutlich
kleiner als n ′ . Jedes erreichbare Objekt erfordert mindestens eine darauf verweisende
Kante, weil es sonst nicht zu erreichen wäre. Damit gilt, das n ′ ≤ m ist und somit
eine parallele Traversierung mit weniger Verarbeitungsschritten als eine sequenzielle
Traversierung ablaufen kann.
Satz 5.4.2 (Parallele Traversierung)
Die parallele Traversierung eines Objektgraphen mit n ′ erreichbaren Knoten und m
Kanten benötigt k Verarbeitungsschritte. k ist die maximale Entfernung eines erreichbaren
Objektes von einer Wurzel. Es gilt k ≤ n ′ ≤ m.
Die realisierte Traversierung aus dem HW-GC-Algorithmus ist in ihrer Leistungsfähigkeit
zwischen der sequenziellen und parallelen Traversierung anzusiedeln. Mögliche
Kollisionen auf dem implementierten Bus-System haben großen Einfluss auf die Traversierung.
Eine ComputingPage kann möglicherweise keine eigenen Daten (Aktivierungen) versenden,
weil es die Signale eines anderen Objekts weiterleiten muss. Betrachtet man den
Extremfall, dann treten jedesmal Kollisionen auf, solange noch andere Objekte Daten
versenden. Ein Objekt kann also erst dann seinen Daten auf den Bus schreiben, wenn
die Objekte mit höherer Priorität ihre Referenzlisten abgearbeitet haben. Man erhält ein
sequenzielles Traversierungsschema. Wenn umgekehrt der Objektgraph so aufgebaut
ist, dass es in keinem Fall zu einer Kollision der Busressourcen kommt, dann können
alle aktivierten Objekte gleichzeitig ihre Referenzen abarbeiten und man erhält eine
Traversierungsreihenfolge, die mehr der parallelen Traversierung ähnelt.
Satz 5.4.3 (HW-GC Traversierung)
Die Traversierung im HW-GC-Algorithmus benötigt maximal so viele Schritte wie die
sequenzielle Traversierung. Sie benötigt mindestens genau so viele Verarbeitungsschritte
wie die parallele Traversierung.
Inwieweit der implementierte HW-GC-Algorithmus eher einer sequenziellen oder parallelen
Traversierung ähnelt, hängt von der jeweiligen Objektstruktur ab. Nach Abschnitt
5.1 lassen sich keine verlässlichen Aussagen über diese Struktur treffen. Es muss
daher bei dieser Abschätzung der Leistungsfähigkeit bleiben. Es lässt sich jedoch festellen,
dass die Anzahl der Kollisionen von dem Verhältnis Kanten abhängt und durch eine
Knoten
Umsortierung der Objekte beeinflusst werden kann.

52 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
1
a
1
a
1
a
2
6
2
3
2
2
3
5
7
4 5
6
3
3 3
4
b
7
b
4
b
Sequenzielle Traversierung
mit Tiefensuche
Sequenzielle Traversierung
mit Breitensuche
Nebenläufige Traversierung
Abbildung 5.4: Verschiedene Traversierungen
5.4.2 PageMiss
Wird während der Garbage-Collection eine Kante gelöscht, die bereits traversiert wurde,
besteht die Möglichkeit, dass ein Objekt als aktiv markiert ist, obwohl es tatsächlich
nicht mehr erreichbar ist. Solche Objekte werden erst im nächsten GC-Zyklus korrekt
als Garbage erkannt. Diese Situation wird als PageMiss bezeichnet, weil die ComputingPage
bei der Zusammenstellung von nicht mehr benötigten Objekten verfehlt wird.
Die Häufigkeit von PageMisses liefert eine aussagekräftige Metrik zur Analyse einer
nebenläufigen Garbage-Collection. Weil ein vom PageMiss betroffenes Objekt erst im
folgenden Zyklus freigegeben wird, steigt die mittlere Laufzeit zum Freigeben eines
Objektes an.
Metrik 5.4.2 (PageMiss-Effizienz)
In einem nebenläufigen GC-Algorithmus kann es dazu kommen, dass ein Objekt innerhalb
eines GC-Zyklus als aktiv markiert bleibt, obwohl es bereits nicht erreichbar ist.
Diese Situation wird als PageMiss bezeichnet und ist ein Maß für die Leistungsfähigkeit
des Algorithmus.
Gibt eine Implementierung beispielsweise sämtliche Objekte erst nach zwei Durchläufen
frei, so hätte sich die Laufzeit, bis ein Objekt korrekt als Garbage erkannt wird,
gegenüber der Zeit für einen GC-Zyklus verdoppelt. Tritt umgekehrt in einer Implementierung
für kein Objekt ein PageMiss auf, so ist die mittlere Laufzeit zur Freigabe eines
Objekts identisch mit der Laufzeit eines GC-Zyklus.
Für die Anzahl der PageMisses spielt die gewählte Traversierungsreihenfolge eine entscheidende
Rolle. In Abbildung 5.4 sind der Objektgraph und seine Traversierung mit
drei verschiedenen Verfahren dargestellt. Bei der Tiefen- und der Breitensuche handelt
es sich um sequenzielle Verfahren. Die parallele Suche kann mehrere Knoten zugleich
verarbeiten.
Angenommen ein Mutator löscht zum Zeitpunkt 4 die, mit ’a’ markierte Kante. Zum
Zeitpunkt 5 befindet sich die Traversierung im entsprechend mit 5 markiertem Knoten.

5.4. QUANTITATIVE BETRACHTUNG 53
Knoten, die mit einer kleineren Zahl markiert sind, wurden bereits besucht, Knoten
mit höherer Zahl noch nicht. Nach der Traversierung entstehen die in Abbildung 5.5
aufgeführten Objektgraphen. Die gestrichelten Linien markieren Teile, die immer noch
aktiv markiert sind, obwohl sie tatsächlich bereits nicht mehr erreichbar sind. Es fällt
auf, dass Breitensuche und Tiefensuche zu unterschiedlichen Ergebnissen gelangt sind.
Dies ist insofern überraschend, als die beiden in einem nicht nebenläufigen Algorithmus
bezüglich Funktionalität und Laufzeit identisch sind.
1
1
a
1
a
2
2
3
2
2
3
5
4 5
6
3
3 3
b
b
b
4
7
4
Sequenzielle Traversierung
mit Tiefensuche
Sequenzielle Traversierung
mit Breitensuche
Nebenläufige Traversierung
Abbildung 5.5: Neuer Objektgraph nach löschen der Kante a) zum Zeitpunkt 5
Das geschilderte Beispiel beim Entfernen der Kante ’a’ deutet darauf hin, dass die Tiefensuche
der Breitensuche überlegen ist. Wird im Ausgangsbeispiel statt ’a’ die Kante
’b’ zum Zeitpunkt 4 entfernt, so sieht man, dass auch die Breitensuche ein besseres Ergebnis
erzeugen kann. In Abbildung 5.6 sieht man, dass die Breitensuche den Objektgraph
korrekt erkannt hat. Bei der Breitensuche ist hingegen noch ein Objekt vorhanden,
das bereits nicht mehr erreichbar ist.
1
a
1
a
1
a
2
6
2
3
2
2
3
5
7
4 5
6
3
3 3
4
b
4
b
Sequenzielle Traversierung
mit Tiefensuche
Sequenzielle Traversierung
mit Breitensuche
Nebenläufige Traversierung
Abbildung 5.6: Neuer Objektgraph nach löschen der Kante b) zum Zeitpunkt 4
Allgemein gilt, das die Breitensuche Objekte, die weit unten im Baum stehen, erst später
als die Tiefensuche abarbeitet. Berücksichtigt man die weak generational hypothesis,
die besagt, dass junge Objekte (diese stehen weiter unten im Baum) häufiger gelöscht

54 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
werden, so ist Wahrscheinlichkeit, dass eine Kante noch vor ihrer Abarbeitung entfernt
wird bei der Breitensuche höher. Die Breitensuche verspricht also, eine geringere Anzahl
von PageMisses zu erzeugen.
Eine Tiefensuche durchläuft nacheinander alle Äste bis zum Ende. Gegenüber der
Breitensuche werden somit häufiger Knoten, die nah an einer Wurzel liegen, erst spät
abgearbeitet. Würde in solch einem Knoten eine Referenz gelöscht, wäre durch diese
einzige Operation ein ganzer Teilbaum nicht mehr erreichbar. Die Breitensuche würde
in diesem Fall eine sehr hohe Anzahl von PageMisses erzeugen.
Es gilt also, bei der Entscheidung zwischen Breiten- und Tiefensuche abzuwägen, ob
das seltene Wegfallen von großen Teilbäumen (bei der Tiefensuche) oder aber das häufige
Wegfallen weniger Objekte (bei der Breitensuche) stärker berücksichtigt werden
soll. Blackburn hat in seinen Untersuchungen gezeigt [22], dass in den meisten Fällen
die Tiefensuche bessere Ergebnisse liefert.
Die parallele Traversierung wurde bisher nicht berücksichtigt. Sie erzeugt in beiden
Beispielen ebensoviele PageMisses, wie die jeweils ungeeignetere sequenzielle Traversierung.
Dies ist jedoch nicht in einer ungünstigen Traversierungsreihenfolge begründet,
sondern in deren hoher Geschwindigkeit. Weil diese Traversierung nur vier Takte benötigt,
ist der GC-Zyklus beim Löschen der Kanten ’a’ und ’b’ bereits abgeschlossen. Deshalb
wäre es eigentlich korrekt, die Kantenoperation bereits dem nächsten GC-Zyklus
zuzuordnen. In diesem Zyklus würde bei beiden Beispielen der tatsächliche Objektgraph
erkannt, ein PageMiss tritt nicht auf.
Wie erläutert, basiert die Traversierung der vorgestellten Implementierung auf der parallelen
Traversierung. Weil Objekte, die nah an der Wurzel stehen, vor Knoten, die weiter
von der Wurzel entfernt stehen, traversiert werden, besitzt sie mehr Ähnlichkeit mit
einer Breitensuche. Das komplexe Verhalten des Bus-Systems, insbesondere seine zeitliche
Verzögerung der Signale mit Registern und die Auflösung von Ressourcenkonflikten,
macht einen direkten Vergleich mit den Verfahren der Tiefen- oder Breitensuche
unmöglich.
Eine schnellere und ressourcenschonende Hardwarekommunikation wurde deshalb
gegenüber den klassischen Traversierungsverfahren bevorzugt. Eine höhere Anzahl von
PageMisses kann durch die häufigere Ausführung der Garbage-Collection ausgeglichen
werden. Dies ist möglich, weil ein einzelner GC-Zyklus schneller ablaufen kann.
Neben der implementierten Traversierungsreihenfolge lassen sich noch andere Kriterien
finden, die einen Einfluss auf die Zahl der PageMisses haben:
• Ein Kriterium ist das Verhältnis GarbageCollectorGeschwindigkeit . Dieser Faktor gibt
MutatorGeschwindigkeit
an, wie schnell der Garbage Collector im Vergleich zum Programm arbeitet. Je
größer dieser Wert, desto schneller arbeitet der Garbage Collector. Im Idealfall
kann ein GC-Zyklus komplett zwischen zwei Anweisungen des Mutators ausgeführt
werden. Anstelle einer nebenläufigen Garbage-Collection erhält man wieder
eine einfache, sequenzielle Garbage-Collection, in der kein PageMiss auftreten

5.5. HÄUFIGKEIT DER GC-ZYKLEN 55
kann.
• Ein weiterer Faktor für die Anzahl der PageMisses ist die Dichte des Graphen.
Ein PageMiss kann nur dann auftreten, wenn durch das Löschen einer Referenz
auch ein Objekt aus dem Objektgraphen entfernt werden kann. Je mehr Wege
es von den Wurzelknoten zu den erreichbaren Knoten gibt, desto seltener wird
beim Löschen einer Referenz tatsächlich ein Objekt unerreichbar. Je mehr Wege
zu den Objekten es gibt, um so dichter ist der Graph. Eine präzise und kompakte
Formulierung der Dichte ist sehr aufwändig. Ein gut geeignetes Maß, das, ist die
Anzahl aller Kanten, die im aktuellen Objektgraph vorkommen. Bei Bedarf kann
diese Maß noch bezüglich der Anzahl der erreichbaren Objekte normiert werden,
AnzahlallerKanten
indem man
bildet. Damit ist die Dichte nicht mehr von der
AnzahlerreichbareObjekte
Größe des betrachtete Objektgraphen abhängig.
• Wird auf der vorgestellten Plattform ein herkömmliches objektorientiertes Programm
implementiert, dann ist pro Thread (d.h. pro Wurzelknoten) nur eine ComputingPage
während eines GC-Laufs aktiv. Weil der Arbiter in dieser Phase Kommunikation
unterbindet, können auch nur Referenzen in diesem Knoten gelöscht
werden. Außerdem können maximal alle Referenzen entfernt werden, die im Knoten
vorher vorhanden waren.
5.5 Häufigkeit der GC-Zyklen
Mit Hilfe der entwickelten Metriken lässt sich die Leistung des implementierten HW-
GC-Algorithmus bestimmen und mit andere Implementierungen vergleichen. Darüber
hinaus ermöglichen sie eine Optimierung der bestehenden Implementierung.
Die Laufzeit eines GC-Zyklus ist weitgehend festgelegt. Sie hängt von der implementierten
Datenstruktur zur Traversierung und der jeweiligen Objektstruktur ab. Neben
kleinen Optimierungen, die möglicherweise das Einsparen einiger Taktzyklen erlauben,
wäre zur Reduzierung der Laufzeit nur noch das Umkopieren der Objekte von Interesse.
Die Kommunikation zwischen zwei Objekten, deren ComputingPages fünf Blöcke
auseinanderliegen, benötigt aufgrund der dazwischenliegenden Register mindestens
fünf Takte. Würde man die beiden Objekte in zwei nebeneinanderliegende ComputingPages
verschieben, wäre eine Kommunikation in nur einem Takt möglich (siehe
Abschnitt 4.3). Diese Art der Optimierung wird aber aufgrund der eingeschränkten
Möglichkeiten aktueller partiell rekonfigurierbarer Architekturen weder kurz- noch mittelfristig
zu realisieren sein.
Ein weiterer Parameter zur Leistungssteigerung ist die Wahl einer optimalen Wartezeit
zwischen zwei GC-Zyklen. Während eines GC-Zyklus ist die Kommunikation über den
Arbiter deaktiviert. Erfordert der Programmablauf in dieser Zeit eine solche Kommunikation,
dann kommt es zu einer Verzögerung: Das Programm muss warten, bis der

56 KAPITEL 5. ANALYSE DES HW-GC-ALGORITHMUS
GC-Zyklus abgeschlossen ist. Um solche Verzögerungen zu vermeiden, ist also eine
möglichst seltene Ausführung der Garbage-Collection zu empfehlen. Umgekehrt muss
vermieden werden, dass der Programmablauf die Instanziierung weiterer Objekte anfordert,
aber aktuell kein freier Speicherplatz zu Verfügung steht. Auch in diesem Fall
muss das Programm ausgesetzt werden, bis ein GC-Zyklus abgeschlossen ist und freizugebende
Objekte identifiziert hat. In diesem Fall hätte der GC-Zyklus bereits früher
gestartet werden müssen, einen Verzögerung hätte durch eine nebenläufige Implementierung
vermieden werden können.
In der vorgestellten Implementierung wird das Starten der Garbage-Collection über
eine einfache und konstante Verzögerung realisiert. Diese Methode ermöglicht eine
kompakte und wenig fehleranfällige Implementierung. Während der Entwicklung sind
verschiedene Kriterien entwickelt worden, die in einer Ausbaustufe zum optimierten
Starten der Garbage-Collection eingesetzt werden können. Diese Kriterien sind im einzelnen:
• Die Anzahl der freien Objekte. Solange noch ausreichend viele freie Objekte vorhanden
sind, ist ein GC-Zyklus nicht erforderlich.
• Der Erfolg der vorherigen GC-Zyklen. Wenn in den letzten Zyklen nur wenige
oder gar keine weiteren freien Objekte gefunden wurden, so wird auch der nächsten
GC-Zyklus wahrscheinlich nicht mehr Speicher freigeben können. In diesem
Fall kann der Start der nächsten Garbage-Collection nach hinten verschoben werden.
• Wenn die Ausführungszeit der Garbage-Collection gegenüber der Ausführungszeit
einer Methode des Mutators kurz ist, dann ist auch der Arbiter nur für kurze
Zeit gesperrt. Die Gefahr, den Mutator zu behindern ist damit geringer und die
Garbage-Collection kann häufiger laufen. Um die Ausführungszeiten zu vergleichen,
ist eine Analyse des Programmablaufs notwendig um zumindest näherungsweise
zu bestimmen, wie oft eine Kommunikation über den Arbiter benötigt wird.

Kapitel 6
Zusammenfassung
6.1 Ergebnisse
In dieser Diplomarbeit wurde die Realisierbarkeit einer automatischen Speicherverwaltung
(Garbage-Collection) für rekonfigurierbare Hardwarestrukturen untersucht. Die
Speicherverwaltung ist dabei in eine neuartige, objektorientierte Entwurfsmethodik eingebunden,
deren Ziel eine flexiblere Anwendungsentwicklung für Hardware ist.
Zuerst wurden die existierenden Mechanismen zur Garbage-Collection erarbeitet und
bezüglich ihrer Tauglichkeit für rekonfigurierbare Hardwarestrukturen untersucht. Die
Mark-Sweep-Collection hat sich hierbei als günstigstes Konzept erwiesen. Aufbauend
auf dem Basis-Algorithmus wurden die Erweiterungsmöglichkeiten der Mark-Sweep-
Collection untersucht. Die Erweiterung zu einem nebenläufigen Algorithmus ist für eine
Umsetzung in Hardware besonders geeignet. Sie steigert die Geschwindigkeit der
Garbage-Collection erheblich und ist in Hardware einfach zu realisieren.
In einem nächsten Schritt sind die ausgewählten Mechanismen entsprechend der Rahmenbedingungen
einer FPGA-basierten Hardwareumgebung modifiziert und angepasst
worden. Insbesondere für die Traversierung im Mark-Schritt wurden besondere Strukturen
entwickelt, um die Bedingungen der Plattform optimal auszunutzen. Schließlich
wurden die einzelnen Mechanismen zu einem einzigen Algorithmus, dem HW-GC-
Algorithmus, zusammengeführt.
Es wurde gezeigt, dass die Leistungsfähigkeit des Algorithmus von den benötigten
Systemressourcen abhängt, insbesondere den Kommunikationsressourcen. Der vorgestellte
Algorithmus ist auf geringen Ressourcenbedarf ausgerichtet und benötigt nur
zwei zusätzliche globale Signale. Für die übrigen Signale lassen sich die existierenden
Kommunikationsressourcen nutzen, die während der Garbage-Collection durch den Arbiter
inaktiv geschaltet sind.
Dank der Ausnutzung nebenläufiger Mechanismen bei der Traversierung der Objekte
und dem parallelen Ausführen von Mutator und Collector bleibt die Garbage-Collection

58 KAPITEL 6. ZUSAMMENFASSUNG
trotzdem hoch performant.
Der Algorithmus wurde mit Hilfe einer Softwaresimulation auf seine Korrektheit geprüft.
Eine informelle Verifikation hat die korrekte Funktionalität des entworfenen Algorithmus
bestätigt.
Die existierenden Methodiken zur Messung der Leistungsfähigkeit haben sich als unzureichend
erwiesen. Sie lassen sich nicht auf den vorgestellten Algorithmus anwenden,
weil sie von klassischen Softwareumgebungen ausgehen.
Um die Leistungsfähigkeit des hardwarebasierten GC-Algorithmus quantitativ beurteilen
zu können, mussten neue Metriken entwickelt werden. Sie erlauben einen Vergleich
des HW-GC-Algorithmus mit anderen Implementierungen und bilden die Grundlage
für weitere Optimierungen des Algorithmus.
6.2 Ausblick
Der vorgestellte Algorithmus wirft weitere Problemstellungen auf, die im Rahmen dieser
Arbeit nicht behandelt werden konnten.
Zum Zeitpunkt der Fertigstellung dieser Arbeit ist die Laufzeitumgebung zur Ausführung
objektorientierter Programme noch nicht abgeschlossen. Der HW-GC-Algorithmus
ist, soweit möglich, in die bestehende Implementierung integriert. Die Ausführung einer
reellen Anwendung ist jedoch noch nicht möglich. Präzisere Aussagen bezüglich der
Leistungsfähigkeit der Implementierung lassen sich treffen, sobald diese Möglichkeit
besteht. Allerdings limitieren weiterhin die eingeschränkten Ressourcen der Hardwareplattform
die Anzahl der realisierbaren Programme.
Eine Möglichkeit, die maximal verfügbaren Systemressourcen zu erweitern ist es,
mehrere gekoppelte FPGAs zu verwenden. Es ist abzusehen, dass die Kommunikation
mit einem anderen Chip deutlich mehr Zeit erfordern wird, als innerhalb eines Chips.
Die Auswirkungen einer solchen, verteilten Architektur auf den Traversierungsalgorithmus
sollten untersucht werden.
Desweiteren gilt es zu überprüfen, welche Möglichkeiten zukünftige dynamisch rekonfigurierbare
Plattformen bieten. Neben einer höheren Zahl von Objekten sind insbesondere
die Möglichkeiten zum Verschieben von logischen Blöcken interessant, weil
für die Laufzeit der Traversierung die geometrische Position einer ComputingPage von
Bedeutung ist. Wenn die Möglichkeit besteht, diese Position mit vertretbarem Zeitaufwand
zu verändern, sollte untersucht werden, ob die Garbage-Collection davon profitieren
kann.
Die Möglichkeiten zur Laufzeitoptimierung der Garbage-Collection müssen weiter
verfeinert werden. Hierfür ist die Wartezeit zwischen zwei GC-Läufen von besonderer
Relevanz, weil sie sich beliebig festlegen lässt. Besonders interessant wäre eine, auf
dem Erfolg des letzten GC-Zyklus basierende, dynamische Anpassung der Zeit zwischen
zwei Wartezyklen, da Lösung nur wenig zusätzlichen Aufwand erfordert. Ihre

6.2. AUSBLICK 59
Leistungsfähigkeit muss allerdings erst evaluiert werden.
Andere, komplexere Algorithmen zur Garbage-Collection, wie etwa die Generational
Collection erfordern einen deutlichen Mehraufwand bei der Verwaltung der Objekte.
Es muss untersucht werden, ab welcher Komplexität der implementierten Programme
dieser Mehraufwand gerechtfertigt ist und zu einer höheren Gesamtleistung führt.
Schließlich sollte in Betracht gezogen werden, ob sich der entworfene Algorithmus
auch bei anderen Problemstellungen einsetzen lässt. Insbesondere die effiziente Traversierung
eines Graphen bietet sich für eine Vielzahl von Anwendungen an.

60 KAPITEL 6. ZUSAMMENFASSUNG

Literaturverzeichnis
[1] B. Mayer, “Object-Oriented Software Construction, Second Edition”, Prentice
Hall ISBN 0-13-629155-4 March 21, 2000.
[2] A. Kühn, S. Huss, “Dynamically Reconfigurable Hardware for Object Oriented
Processing” International Conference on Parallel Computing in Electrical
Engineering, Dresden, Germany September 2004.
[3] Xilinx, “Programmable Logic Data Book,” 2001.
[4] Xilinx, “XAPP290 : Two Flows for Partial Reconfiguration : Module Based or
Small Bit Manipulations,” Xilinx Application Notes, 2004
[5] Xilinx, Inc., “ISE Foundation 6.3i”
http://www.xilinx.com/products/design_resources/design_tool/
[6] Alpha Data Parallel Systems Ltd., “ADC-PMC-64 User Manual”, Ver. 1.1, 2002.
[7] Synplicity, Inc., “Synplify Pro 8.0”
http://www.synplicity.com/products/synplifypro/index.html
[8] B.W. Kernighan, D. Ritchie, “C Programming Language, Second Edition”,
Prentice Hall ISBN 0131103628
[9] P. Roy, S. Seshadri, A. Silberschatz, S. Sudarshan, S. Ashwin, “Garbage collection
in object-oriented databases using transactional cyclic reference counting”
The VLDB Journal, 7(3):179-193, 1998.
[10] A. Diwan, D. Tarditi, E. Moss, “Memory subsystem performance of programs
using copying garbage collection”, Proceedings of the 21st ACM SIGPLAN-
SIGACT symposium on Principles of programming languages, February 1994
[11] E. W. Dijkstra, L. Lamport, A. J. Martin, C. S. Scholten, E. F. M. Stevens, “Onthe-Fly
Garbage Collection: An Exercise in Cooperation”, Communications of
the ACM, 21(11):966-957, November 1978.

62 LITERATURVERZEICHNIS
[12] L. Huelsbergen, P. Winterbottom, “Very Concurrent Mark-&-Sweep Garbage
Collection without Fine-Grain Synchronization”, ACM SIGPLAN Notices Volume
34 Issue 3, Proceedings of the 1st international symposium on Memory
management, October 1998
[13] M. Ben-Ari, “Algorithms for On-the-fly Garbage Collection”, ACM Transactions
on Programming Languages and Systems (TOPLAS), Volume 6 Issue 3, July
1984
[14] D. Doligez, G. Gonthier, “Portable, unobtrusive garbage collection for multiprocessor
systems”, Proceedings of the 21st ACM SIGPLAN-SIGACT symposium
on Principles of programming languages, February 1994
[15] T. Domani, E. K. Kolodner, E. Lewis, E. E. Salant, K. Barabash, I. Lahan, Y.
Levanoni, E. Petrank, I. Yanorer, “Implementing an on-the-fly garbage collector
for Java”, ACM SIGPLAN Notices , Proceedings of the 2nd international
symposium on Memory management, Volume 36 Issue 1, October 2000
[16] D. Doligez, X. Leroy, “A concurrent, generational garbage collector for a multithreaded
implementation of ML”, Proceedings of the 20th ACM SIGPLAN-
SIGACT symposium on Principles of programming languages, March 1993
[17] J. Seligmann, S. Grarup, “Incremental Mature Garbage Collection Using the
Train Algorithm”, Proceedings of ECOOP’95, Ninth European Conference on
Object-Oriented Programming, Lecture Notes in Computer Science, Vol. 952,
pp. 235-252, 1995
[18] H. Lieberman, C. Hewitt, “A Real-Time Garbage Collector Based on the Lifetime
of Objects”, Communications of the ACM, 26(6):419-429, June 1983.
[19] M. Hirzel, A. Diwan, M. Hertz, “Connectivity-based garbage collection”, ACM
SIGPLAN Notices , Proceedings of the 18th annual ACM SIGPLAN conference
on Object-oriented programing, systems, languages, and applications, Volume
38 Issue 11, October 2003
[20] T.H. Cormen, C.E. Leiserson, R.L. Rivest, “Introduction to Algorithms”, MIT
Press, ISDB 0-262-53091-0
[21] B. Zorn, D. Grunwald “Evaluating Models of Memory Allocation”, ACM Transactions
on Modeling and Computer Simulation, 4(1):107-131, January 1994
[22] S. Blackburn, P. Cheng, K.S. McKinley, “Myths and Realities: The Performance
Impact of Garbage Collection” Proceedings of ACM SIGMETRICS/Performance,
ACM 1-58113-873-3/04/0006, June 2004

LITERATURVERZEICHNIS 63
[23] M. Hirzel, J. Henkel, A. Diwan, M. Hind “Understanding the Connectivity of
Heap Objects” Proceedings of ISSM ’02, ACM 1-58113-539-4/02/0006, June
2002
[24] C. Ruggieri, T.P. Murtagh, “Lieftime Analysis of Dynamically Allogcated Objects”
Proceedings of 15th Annual ACM SIGACT-SIGPLAN Symposium on Principles
of Programming Languages, January 19989
[25] D. Stefanovic, K.S. McKinley, J.E.B. Moss, “On Models for Object Lifetime
Distribuntions” Proceedings of ISSM ’00, ACM 1-58113-263-8/00/10, October
2000
[26] S. Oaks, H. Wong, “Java Threads, Third Edition” O’Reilly, ISBN 0596007825
[27] J. Gosling, B. Joy, G. Steele, G. Bracha, “Java(TM) Language Specification,
Third Edition” Addison-Wesley Professional, ISBN: 0321246780