(Mostly) Concurrent Garbage Collection Seminar aus Softwareentwicklung: Garbage Collection Günther Gsenger

(2/19) Übersicht Einleitung Idee des Algorithmus Implementierung von Boehm et al. Implementierung von Printezis, Detlefs Benchmarks

(3/19) Einleitung (1/2) Verschiedene Algorithmen der Garbage Collection Gemeinsamkeit: Stop-the-world-Phase Daher hohe Latenz von Programmen mit Garbage Collection Ungeeignet für: Echtzeitsysteme Serveranwendungen mit großen Datenmengen gewisse Desktopanwendungen

(4/19) Einleitung (2/2) Idee: Garbage Collector Thread parallel zu den Mutator Threads ablaufen lassen. Stop-the-world-Phasen minimieren Offensichtliche Probleme: Synchronisation im Allokator Mehrere Garbage Collectoren? Probleme

(5/19) Algorithmus - Probleme

(6/19) Algorithmus – Probleme + Lösung Wenn Referenzen in Objekten verändert werden, die bereits markiert sind, kann es zur Löschung von noch referenzierten Objekten kommen Lösung: Write-Barrier ( Unterstützung der Plattform) Objekte werden nicht gelöscht, obwohl sie nicht mehr referenziert werden Lösung: Bedauerlich aber diese Objekte werden beim nächsten Collection Zyklus mit Sicherheit gelöscht

(7/19) Algorithmus – Unterstützung der Plattform Plattform teilt dem Collector mit, wenn ein bereits markiertes Objekt verändert wird Der Collector kann diese Objekte erneut überprüfen Dadurch wird sichergestellt, dass keine referenzierten Objekte freigegeben werden Anderes Problem besteht weiterhin, wird vernachlässigt

(8/19) Boehm et al. - Einleitung Größtenteils paralleler Garbage Collector für primitive Sprachen wie C/C++ (1991) Keine Unterstützung einer virtuellen Maschine Unterstützung der Hardware Speicherschutzfunktionen der Hardware werden missbraucht Virtuelle Seiten auf read only gesetzt, Speicherschutzfehler-Signal abgefangen Signal deutet auf Veränderung innerhalb einer Speicherseite hin

(9/19) Boehm et al. - Beispiel Selbes Beispiel wie vorhin Signal, dass Seite verändert wurde wird abgehandelt und Seite gespeichert Gesamte veränderte Seite muss neu überprüft werden

(10/19) Boehm et al. - Nachteile Großer Overhead: Prozessor-Exception, Kontext-Switch zum/vom Betriebssystem Ungenaue Informationen: Virtuelle Speicherseiten sind üblicherweise im Userspace 4096 Byte groß. Alle Objekte in einer veränderten Seite müssen geprüft werden Ungenaue Typinformationen: Auch bei Schreibzugriffen auf nicht-Zeiger werden Speicherseiten invalidiert Anwendungsspezifisches Tuning: Wenn der Mutator mehr Speicher allokiert als der Collector freigibt, muss Speicher ausgelagert werden

(11/19) Printezis, Detlefs - Einleitung Generationeller, größtenteils nebenläufiger Garbage Collector für die Sun Microsystems Virtual Machine for Research (2000) Unterstützung der Plattform auf Softwareebene gegeben: Card Table Barrier Mod Union Table (neu eingeführt) Collector wird für Collection Zyklen in der alten Generation eingesetzt

(12/19) Card Table, Mod Union Table, 2- Instruction-Barrier Card Table wird von generationellem Garbage Collector benötigt, um Referenzen der alten Generation auf die junge zu erfassen Speicher wird in Karten mit Größe 2 k Bytes unterteilt Barrier ist Instruktionsfolge, die bei jedem Schreiben auf einen Zeiger die Speicherkarte markiert Schneller 2-Instruktionsbarrier wie von Urs Hölzle vorgeschlagen wird eingesetzt Mod Union Table ist Vereinigung der veränderten Karten. Wird von parallelem GC benötigt. Wird vom GC der jungen Generation vor Einsammlungszyklus geschrieben Invarianz zwischen Card Table und Mod Union Table.

(13/19) Card Table, Mod Union Table, 2- Instruction-Barrier ; ptr im Feld des Objekts speichern st[%obj + offset], %ptr ; den ungefähren Byte-Index berechnen sll%obj, k, %temp ; das Byte im Card Table löschen st%g0, [%byte_map + %temp]

(14/19) Mark & Sweep Mark-Phase: Externer Markierungsbitvektor Heap wird linear durchsucht Referenzen zurück im Speicher werden gleich untersucht Objekte, die nach der aktuellen Position sind nur markiert

(15/19) Mark & Sweep Sweep-Phase: Auch nebenläufig zum Mutator Vor Verändern der Blocklisten muss Lock angefordert werden Schnelles Durchsuchen des Markierungsbitvektors möglich

(16/19) Kontrollheurisitiken Wettrennen zwischen Mutator und Collector: Wer allokiert/delokiert schneller? Bei Multiprozessorsystemen: Collector arbeitet so schnell er kann, verliert möglicherweise das Rennen Bei Uniprozessorsystemen: Collector macht seine Pausen kürzer, wenn er merkt, dass er zu weit zurückfällt. Im Notfall: Notstopp des Programms und sequentielle Collection

(17/19) Printezis, Detlefs – Vor-/Nachteile + Weniger Overhead + Feinere Unterteilung der Art der Speicherzugriffe + Feinere Granularität + Parallelität zu anderen GC + Kontrollheuristiken - Großer Speicheroverhead wegen Markierungsbitvektor (3,125%) - Lineare Heapsuche

(18/19) Benchmarks

(19/19) Ende Danke für die Aufmerksamkeit