|
Nur so als Hinweis: Die verschiedenen Techniken lassen sich kombinieren. Der GC von VisualWorks besteht z. B. aus einem sog. Generation Scavenger, einem Incrementellen GC und einem Kompaktifizierer. Außerdem kann auch die Objektbasis für den Suchalgorithmus bereinigt werden (globaler GC für den Permanentspeicher), was ein Standardschritt beim Deployment ist. Will man C-Routinen ansprechen, sind wieder andere Mechanismen wie z. B. explizite Heap-Kopie oder Schutz vor dem GC erforderlich. |
== GC in Java == |
Vor Speicherzugriffsfehlern der VM braucht man nach meiner Erfahrung kaum Angst zu haben. Problematischer wird's bei der Parametriesierung des GC. Anwendungen mit speziellen Anforderungen an den GC müssen adäquate Werte setzen oder eine Unterklasse der Standard-Memory-Policy schreiben. |
* IBM-Java, siehe Artikelserie Teil 1, Teil 2 == GC in Smalltalk == Die oben genannten Techniken werden kombiniert. Der GC von VisualWorks besteht z. B. aus einem sog. Generation Scavenger, einem Incrementellen GC und einem Kompaktifizierer. Außerdem kann auch die Objektbasis für den Suchalgorithmus bereinigt werden (globaler GC für den Permanentspeicher), was ein Standardschritt beim Deployment ist. Will man C-Routinen ansprechen, sind wieder andere Mechanismen wie z. B. explizite Heap-Kopie oder Schutz vor dem GC erforderlich. Vor Speicherzugriffsfehlern der VM braucht man kaum Angst zu haben. Problematischer wird's bei der Parametriesierung des GC. Anwendungen mit speziellen Anforderungen an den GC müssen adäquate Werte setzen oder eine Unterklasse der Standard-Memory-Policy schreiben. |
Eine auf deutsch verfasste Einführung: http://www.ssw.uni-linz.ac.at/Teaching/Lectures/Sem/2003/reports/Kusel/Kusel.pdf
Algorithmen zur GarbageCollection |
Es gibt viele Algorithmen zur Implementierung von GarbageCollection, die alle ihre Vor- und Nachteile haben und die unterschiedlich komplex sind.
Tracing GC vs ReferenzZählung' Streng genommen gehört ReferenzZählung als Gegenstück zur "Tracing GC" (Verfolgenden GC) auch zur GarbageCollection, üblicherweise aber trennt man es strikt, und meint mit GC nur die "Tracing GC".
Kopierende GC: "Stop & Copy" verursacht die berühmten Pausen, ist aber relativ leicht zu implementieren und hält den Hauptspeicher kompakt. Kopierende GC sind "kompaktierend", dh. sie verursachen keine Löcher wie bei Mark-Sweep, malloc oder ReferenzZählung.
Verteilte GC: Wird in Systemen mit nicht durchgehenden Hauptspeicher Segmenten verwendet, zB. in verschiedenen Threads, privaten CPU-Heaps oder verschiedenen Maschinen. Auf WAN-System ist der Verwaltungsaufwand zur Synchronisation und Kommunikation sehr hoch, daher wird statt Tracing GC, üblicherweise "gewichtete ReferenzZählung" eingesetzt. (In DCOM nur ungewichtete ReferenzZählung). http://www.xanalys.com/software_tools/mm/glossary/w.html#weighted.reference.counting
Generationelle GC: Ein GC mit Trennung in verschiedene Altersklassen der Objekte, der sehr gut durch moderne CPU-Caches und moderne Sprachen unterstützt wird. Diese GC's sind üblicherweise die schnellsten. http://www.xanalys.com/software_tools/mm/glossary/g.html#generational.garbage.collection
Inkrementelle GC: Einfache GC's können in ihrer Ausführung nicht unterbrochen werden. Inkrementelle GC können durch Pausen unterbrochen werden, ohne inkonsistente Daten zu hinterlassen. Dadurch sind sie für Echtzeit- und hoch interaktive Anwendungen geeignet. http://www.xanalys.com/software_tools/mm/glossary/i.html#incremental.garbage.collection
Parallelle GC: Ein GC für Multiprozessorsysteme, der ähnlich aber schwieriger als ein inkrementeller GC ist, implementiert mit Hilfe von "Barriers" (Software oder Hardware Unterstützung bei LOAD und STORE ops). http://www.xanalys.com/software_tools/mm/glossary/p.html#parallel.garbage.collection
Vergleich ReferenzZählung - GarbageCollection:
Außerdem, wer verwendet schon den C alloca? In guten Lisp's, ML's oder scheme passiert das automatisch, da der Compiler mehr weiß und Funktionsaufrufe besser optimieren kann. (-> automatische SpeicherVerwaltung)
Siehe auch:
GC in Java |
GC in Smalltalk |
Die oben genannten Techniken werden kombiniert. Der GC von VisualWorks besteht z. B. aus einem sog. Generation Scavenger, einem Incrementellen GC und einem Kompaktifizierer. Außerdem kann auch die Objektbasis für den Suchalgorithmus bereinigt werden (globaler GC für den Permanentspeicher), was ein Standardschritt beim Deployment ist. Will man C-Routinen ansprechen, sind wieder andere Mechanismen wie z. B. explizite Heap-Kopie oder Schutz vor dem GC erforderlich.
Vor Speicherzugriffsfehlern der VM braucht man kaum Angst zu haben. Problematischer wird's bei der Parametriesierung des GC. Anwendungen mit speziellen Anforderungen an den GC müssen adäquate Werte setzen oder eine Unterklasse der Standard-Memory-Policy schreiben.
Auf den Seiten von Cincom gibt es hochinteressante aber mitunter leider schwer zu findende Dokumente über das Memory-Management von VisualWorks. Einen ersten Überblick gibt
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/DOWNLOAD/DOCS/memory-VW3.x.pdf