Garbage Collection

Die Garbage Collection, kurz GC (englisch für Müllabfuhr, auch automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Software- und Informationstechnik eine automatische Speicherverwaltung, die zur Vermeidung von Speicherproblemen beiträgt; der Vorteil wird mit einem erhöhten Ressourcenverbrauch erkauft. Unter anderem wird der Speicherbedarf eines Computerprogramms minimiert. Dabei wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben. Manche automatischen Speicherbereinigungen führen darüber hinaus die noch verwendeten Speicherbereiche zusammen (Defragmentierung).

In vielen Softwaresystemen wird benötigter (Arbeits-)Speicher dynamisch (bei Bedarf) reserviert. Wird er nach Abarbeitung eines Programmteils nicht weiter verwendet, so sollte der Speicher wieder freigegeben werden, um eine Wiederverwendung dieser Ressource zu ermöglichen. Bei einer expliziten, manuellen Speicherverwaltung geschieht dies durch Festlegen der Speicherreservierung und -freigabe im Programm durch den Programmierer, ein schnell komplex und damit potenziell fehlerträchtig werdendes Vorgehen. Neben dem Vergessen einer Freigabe, das längerfristig zu Speicherknappheit führen kann, führt das zu frühe Freigeben von (anderswo) noch benötigtem Speicher meist schnell zum Programmabsturz. Vergessene Speicherfreigaben führen oft nicht sofort zu Auffälligkeiten im Programmablauf – zumindest nicht während der typischerweise nur kurzen Programmläufe während der Entwicklung, sondern erst, wenn das fertige Programm vom Endanwender oft über Stunden und Tage ununterbrochen betrieben wird.

Bei manueller Speicherverwaltung ist es oft nicht möglich oder sehr aufwendig, den Speicher zu defragmentieren. Stark fragmentierter Speicher kann dazu führen, dass eine Speicherreservierung des Programms fehlschlägt, da kein ausreichend großer zusammenhängender Bereich verfügbar ist.

Bei der automatischen Speicherbereinigung ist die Idee, diese Aufgabe durch eine Garbage Collector genannte Routine automatisch erledigen zu lassen, ohne Zutun des Programmierers. D. h. das Speichermanagement wird von einer expliziten Festlegung zur Programmerstellungszeit (Compile-Zeit) zu einer dynamischen Analyse des Speicherbedarfs zur Laufzeit des Programms verschoben.

Üblicherweise läuft eine solche automatische Speicherbereinigung im Hintergrund (bzw. nebenläufig) in mehr oder minder regelmäßigen Zeitabständen (z. B. während Pausen im Programmablauf) und wird nicht explizit durch das Programm ausgelöst. GC kann jedoch häufig auch zusätzlich direkt ausgelöst werden, um dem Programm etwas Kontrolle über die Bereinigung zu geben, z. B. in einer Situation von Speichermangel (Out-Of-Memory).

Es gibt verschiedene Ansätze, um eine automatische Speicherbereinigung zu implementieren. Gewünschte Anforderungen können ein möglichst geringer Speicherverschnitt, eine maximale Allozierungsgeschwindigkeit, eine Reduktion der Speicherfragmentierung und viele weitere mehr sein, die sich durchaus auch widersprechen und zu Zielkonflikten führen können. D. h. je nach Anwendungsfall kann eine automatische Speicherbereinigung sehr unterschiedlich aussehen und sicher viele Anforderungen erfüllen, manche aber auch nicht.

Typischerweise werden jedoch alle diese Varianten zwei Grundtypen von Speicherbereinigungen zugeordnet: Konservative und nicht-konservative Speicherbereinigung.

Unter einer konservativen automatischen Speicherbereinigung versteht man eine, die nicht zuverlässig alle nicht-referenzierten Objekte erkennen kann. Diese hat meistens keine Informationen darüber, wo sich im Speicher Referenzen auf andere Objekte befinden. Zur Speicherbereinigung muss sie den Speicher auf mögliche Referenzen durchsuchen. Jede Bitfolge, die eine gültige Referenz in den Speicher sein könnte, wird als Referenz angenommen. Es kann dabei nicht festgestellt werden, ob es sich dabei nicht doch um ein Zufallsmuster handelt. Daher erkennen konservative Kollektoren gelegentlich Objekte als referenziert, obwohl sie es eigentlich nicht sind. Da eine automatische Speicherbereinigung niemals Objekte entfernen darf, die noch gebraucht werden könnten, muss sie konservativ annehmen, dass es sich bei der erkannten Bitfolge um eine Referenz handelt.

Insbesondere wenn eine automatische Speicherbereinigung auch dringlichere Ressourcen als Speicher freigeben muss (siehe Finalisierung), kann ein konservativer Kollektor ein Risiko darstellen. Im Allgemeinen findet man konservative GCs dort, wo interne Pointer (also Pointer auf unterschiedliche Teile eines Objektes) erlaubt sind, was eine Implementierung der automatischen Speicherverwaltung erschwert. Beispiele dafür sind die Sprachen C und C++. Hier sei anzumerken, dass dies nicht für die verwalteten Typen in C++/CLI gilt, da dort eigene Referenztypen für die automatische Speicherbereinigung eingeführt wurden, die es nicht erlauben, direkt die Adresse eines Objekts auszulesen.

Unter einer nicht-konservativen automatischen Speicherbereinigung (manchmal auch als exakte Speicherbereinigung bezeichnet) versteht man eine, der Metadaten vorliegen, anhand derer sie alle Referenzen innerhalb von Objekten und Stackframes auffinden kann. Bei nicht-konservativer Speicherbereinigung wird zwischen Verfolgung (tracing garbage collectors) und Referenzzählung unterschieden.

Bei diesem Verfahren der Speicherbereinigung wird von bekanntermaßen noch benutzten Objekten ausgehend allen Verweisen auf andere Objekte gefolgt. Jedes so erreichte Objekt wird markiert. Anschließend werden alle nicht markierten Objekte zur Wiederverwendung freigegeben.

Die Freigabe kann zur Speicherfragmentierung führen. Das Problem ist hierbei jedoch etwas geringer als bei manueller Speicherverwaltung. Während bei manueller Speicherverwaltung die Deallozierung immer sofort erfolgt, werden bei Mark-and-Sweep fast immer mehrere Objekte auf einmal beseitigt, wodurch größere zusammenhängende Speicherbereiche frei werden können.

Der Mark-and-Compact-Algorithmus benutzt ebenso wie Mark-and-Sweep das Prinzip der Erreichbarkeit in Graphen, um noch referenzierte Objekte zu erkennen. Diese kopiert er an eine andere Stelle im Speicher. Der ganze Bereich, aus dem die noch referenzierten (man spricht hier auch von „lebenden“) Objekte herauskopiert wurden, wird nun als freier Speicherbereich betrachtet.

Nachteil dieser Methode ist das Verschieben der „lebenden“ Objekte selber, denn Zeiger auf diese werden ungültig und müssen angepasst werden. Hierzu gibt es grundsätzlich wenigstens zwei Verfahren:

1. Jedes Objekt wird über zwei Indirektionen (Umleitungen) angesprochen (über einen Zeiger auf einen Zeiger auf das Objekt), so dass beim Verschieben nur noch der Zeiger, der direkt auf das Objekt zeigt, angepasst werden muss.
2. Alle Referenzen verweisen direkt auf das Objekt, um aufwändige Dereferenzierungen zu vermeiden, und werden nach einer Verschiebung geeignet angepasst.

Das Verschieben der Objekte hat allerdings den Vorteil, dass jene, die die Bereinigung „überlebt“ haben, nun alle kompaktiert zusammenliegen und der Speicher damit praktisch defragmentiert ist. Auch ist es möglich, sehr schnell zu allozieren, weil freier Speicherplatz nicht aufwändig gesucht wird. Anschaulich: Werden die referenzierten Objekte an den „Anfang“ des Speichers verschoben, kann neuer Speicher einfach am „Ende“, hinter dem letzten lebenden Objekt, alloziert werden. Das Allozieren funktioniert damit vergleichsweise einfach, ähnlich wie beim Stack.

Generationelle GCs verkürzen die Laufzeit der Speicherfreigabe. Dazu wird die Situation ausgenutzt, dass in der Praxis die Lebensdauer von Objekten meist sehr unterschiedlich ist: Auf der einen Seite existieren Objekte, die die gesamte Laufzeit der Applikation überleben. Auf der anderen Seite gibt es eine große Menge von Objekten, die nur temporär für die Durchführung einer einzelnen Aufgabe benötigt werden. Der Speicher wird bei generationellen GCs in mehrere Teilbereiche (Generationen) aufgeteilt. Die Langlebigkeit wird durch einen Zähler quantifiziert, welcher bei jeder Garbage-Collection inkrementiert wird. Mit jeder Anwendung des Freigabe-Algorithmus (zum Beispiel Mark-and-Compact oder Stop-And-Copy) werden langlebige Objekte in eine höhere Generation verschoben. Der Vorteil liegt darin, dass die Speicherbereinigung für niedrige Generationen häufiger und schneller durchgeführt werden kann, da nur ein Teil der Objekte verschoben und deren Zeiger verändert werden müssen. Höhere Generationen enthalten mit hoher Wahrscheinlichkeit nur lebende (bzw. sehr wenige tote) Objekte und müssen deshalb seltener bereinigt werden.

Die Anzahl der Generationen wird heuristisch festgelegt (zum Beispiel drei in .NET, zwei für junge Objekte (auch Young-Generation genannt) und einer für alte Objekte (Tenured-Generation) in der Java-VM von Sun). Zudem können für jede Generation unterschiedliche Algorithmen verwendet werden. In Java beispielsweise wird für die niedrigste Generation ein modifizierter Stop-And-Copy-Algorithmus angewandt, für die höhere Mark-And-Compact.

Bei diesem Verfahren führt jedes Objekt einen Zähler mit der Anzahl aller Referenzen, die auf dieses Objekt zeigen. Fällt der Referenzzähler eines Objektes auf null, so kann es freigegeben werden.

Ein besonderes Problem der Freispeichersammlung mit Referenzzählung liegt in so genannten zyklischen Referenzen, bei denen Objekte Referenzen aufeinander halten, aber sonst von keinem Konsumenten im System mehr verwendet werden. Nehmen wir beispielsweise an, Objekt A halte eine Referenz auf Objekt B und umgekehrt, während der Rest des Systems ihre Dienste nicht mehr benötigt. Somit verweisen beide Objekte gegenseitig (zyklisch) aufeinander, weshalb die automatische Speicherbereinigung nicht ohne weiteres erkennen kann, dass sie nicht mehr benutzt werden. Die Folge hiervon ist, dass der Speicher somit für die Dauer der Programmausführung belegt bleibt. Es gibt unterschiedliche Algorithmen, die solche Situationen erkennen und auflösen können, zumeist nach dem Prinzip der Erreichbarkeit in Graphen.

Mit einer Garbage Collection können einige häufig auftretende Programmierfehler, die beim Umgang mit dynamischer Speicherverwaltung oft gemacht werden, ganz oder zumindest teilweise vermieden werden. Besonders zu erwähnen sind hierbei Speicherlecks, die doppelte Freigabe von Ressourcen und die Dereferenzierung von versehentlich zu früh freigegebenen Ressourcen (Hängende Zeiger). Eine Freigabe noch referenzierter Objekte führt zu hängenden Zeigern, welche oft zu Programmabstürzen und undeterministischem Verhalten führen.

Als Folge des Satzes von Rice kann nicht festgestellt werden, ob noch referenzierte Objekte jemals wieder benutzt werden. Darum gibt eine automatische Speicherbereinigung nur vom Programm nicht mehr referenzierte Objekte frei; sie verhindert keine „Speicherlecks“ der Sorte, dass das Programm auf den Speicherbereich noch eine Referenz hält, den Inhalt jedoch nie wieder nutzt.^[1][2][3] Derartige Speicherlecks stellen normalerweise Logische Fehler oder Designfehler (Fehler im Grundkonzept, falsche Anforderungen an die Software, Softwaredesign-Fehler) dar und können auch bei nicht-automatischer Speicherverwaltung entstehen.

Zusätzlich behebt Garbage Collection das Problem der Speicherfragmentierung, das kein Programmierfehler im eigentlichen Sinne ist, jedoch auf ungünstigem Programmdesign basieren kann. Dieses Problem kann zu nur schwer reproduzierbaren Programmabstürzen führen. Das Problem der Speicherfragmentierung wird von explizitem/manuellem Speichermanagement im Allgemeinen nicht gelöst.

Ob eine automatische Speicherbereinigung Programme insgesamt beschleunigt oder ausbremst, ist umstritten. In einigen Kontexten, wie z. B. wenn Speicher erst dann freigegeben wird, wenn die Systemanforderungen gerade niedrig sind oder wenn die Speicherverwaltung des Systems durch Defragmentierung entlastet wird, kann sie zu Leistungssteigerungen führen. Es existieren Microbenchmarks, welche belegen, dass bei Programmiersprachen mit automatischer Speicherbereinigung die Anlage/Freigabe von Objekten in Summe schneller vonstattengeht als ohne,^[4][5] jedoch auch Microbenchmarks, die insgesamt einen überwiegend negativen Einfluss auf die Leistungsfähigkeit sehen.^[6] Eine Veröffentlichung von 2005 gibt an, dass die Leistungsfähigkeit von Garbage Collection nur dann gleich gut wie oder leicht besser als beim expliziten Speichermanagement sei, wenn der Garbage Collection fünfmal so viel Speicher zusteht, wie tatsächlich benötigt wird. Bei dreimal so viel Speicher liefe Garbage Collection im Schnitt 17 % langsamer, bei doppelt so viel Speicher 70 % langsamer als bei explizitem Speichermanagement.^[7]

Beim Speicherverbrauch führt eine automatische Speicherverwaltung und -bereinigung zu einem Overhead gegenüber einem expliziten, händischen Speichermanagement aufgrund der zeitverzögerten Bereinigung. Eine wissenschaftliche Veröffentlichung von 1993 schätzt den Overhead bei konservativer Speicherbereinigung (wie beispielsweise für die Sprache C erhältlich) auf typischerweise 30–150 %.^[8] Andererseits ist eine korrekte Implementierung manueller Speicherfreigabe in nicht trivialen Programmen komplex umzusetzen, was Fehlerquellen für Speicherlecks bei manueller Speicherfreigabe schafft. Beispielsweise kann die oft angewandte Methode der Referenzzählung keine zyklischen Referenzen erkennen und führt ohne Ergänzung durch komplexe Algorithmen zu Speicherlecks.

Indem der Programmierer die Entscheidung über den Freigabezeitpunkt nicht explizit festlegt, gibt er auch einen Teil der Kontrolle über den Programmfluss auf. Da die automatische Speicherbereinigung i. d. R. nebenläufig stattfindet, hat das Programm selbst keine Information darüber, wann Speicherbereiche wirklich freigegeben bzw. Objekte finalisiert werden. Dadurch ist der Programmfluss potentiell nicht mehr deterministisch.^[9]

Konkret können folgende Formen nicht-deterministischen Verhaltens auftreten:

• Der Zeitpunkt der Finalisierung ist unbestimmt: Selbst wenn ein Objekt als nicht mehr benötigt erkannt und zur Bereinigung ausgewählt wurde, ist der Zeitpunkt der Finalisierung unbestimmt, dadurch ist auch der Programmfluss nicht mehr deterministisch. Das ist insbesondere dann ein Problem, wenn das Objekt gemeinsam genutzte Ressourcen verwendet oder abschließende Berechnungen durchführt. Derartiges im Zuge der Finalisierung zu machen gilt in der Programmierung als Anti-Pattern.
• Die Laufzeit – sowohl des gesamten Programms als auch nur von einzelnen Abschnitten – kann durch die Unterbrechungen durch den Garbage Collector nicht-deterministisch werden. Das stellt speziell für Echtzeitsysteme ein Problem dar. So ist es in Echtzeitsystemen nicht hinnehmbar, dass die Programmausführung zu unvoraussehbaren Zeitpunkten durch die Ausführung der Speicherbereinigung unterbrochen wird. Für Echtzeitsysteme arbeitet, wie beispielsweise bei Real-Time Java, eine automatische Speicherbereinigung präemptiv (zum Beispiel im Leerlaufprozess) und inkrementell. Einfache inkrementelle Verfahren arbeiten zum Beispiel mit der sogenannten Dreifarb-Markierung.^[10]

Mittels kompaktierender Algorithmen kann Garbage Collection eine Fragmentierung des Speichers verhindern. Siehe dazu Mark and Compact. Damit werden Lücken im Speicher vermieden, die aufgrund zu großer neuer Objekte nicht aufgefüllt werden könnten. Defragmentierung führt zwar zu einer längeren Verzögerung beim Freigeben von Speicher, reduziert allerdings die Allozierungsdauer. Um die Speicherfreigabe möglichst schnell durchführen zu können, wird darauf geachtet, dass möglichst selten große Speicherbereiche aufgeräumt werden müssen. Deshalb werden diese Algorithmen bevorzugt in Kombination mit generationellen Verfahren eingesetzt.

Defragmentierung des Speichers führt zu folgenden Vorteilen:

• Es wird der gesamte zur Verfügung stehende Speicher genutzt.
• Das Allozieren von Speicher dauert kürzer, da die Datenstrukturen, über die der Heap verwaltet wird, weniger komplex werden. Das Suchen nach einer freien Speicherstelle von passender Größe gestaltet sich einfacher.
• Nacheinander allozierte Objekte stehen meist nebeneinander im Speicher (man spricht hierbei von guter Speicherlokalität). Untersuchungen haben gezeigt, dass nacheinander erzeugte Objekte oft gleichzeitig für eine bestimmte Operation gebraucht werden. Wenn sie nahe genug beieinander liegen, erfolgen die Zugriffe auf den schnellen Cache-Speicher und nicht auf den dahinterliegenden, langsameren Speicher.

Als Finalisierung (englisch finalization) bezeichnet man in objekt-orientierten Programmiersprachen eine spezielle Methode, die aufgerufen wird, wenn ein Objekt durch den Garbage Collector freigegeben wird.

Anders als bei Destruktoren sind Finalisierungsmethoden nicht deterministisch: Ein Destruktor wird aufgerufen, wenn ein Objekt explizit durch das Programm freigegeben wird. Die Finalisierungsmethode wird jedoch erst aufgerufen, wenn der Garbage Collector entscheidet, das Objekt freizugeben. Abhängig vom Garbage Collector kann dies zu einem beliebigen Zeitpunkt geschehen, wenn festgestellt wird, dass das Programm das Objekt nicht mehr verwendet – möglicherweise auch nie bzw. am Ende der Laufzeit (siehe auch Abschnitt Determinismus).

Die Finalisierung kann in der Praxis zu Problemen führen, wenn sie für die Freigabe von Ressourcen verantwortlich ist:

• Objekte, die Ressourcen verwalten, sollten diese nicht erst im Zuge der Finalisierung freigeben. Ansonsten könnte das zu blockierenden Zuständen innerhalb des Programmablaufs führen, da der Zeitpunkt der Finalisierung nicht vorhersagbar ist.
• Finalisierung erzeugt zusätzliche Rechenlast für die automatische Speicherbereinigung, welche möglichst rasch und ohne den Rest des Programmablaufes zu stören durchgeführt werden sollte.
• Es gibt keine definierte Finalisierungsreihenfolge. Daher kann es geschehen, dass während der Finalisierung auf andere Objekte zugegriffen wird, die ebenfalls der Finalisierung unterworfen sind, zu diesem Zeitpunkt aber überhaupt nicht mehr existieren.
• Es gibt je nach Implementierung (beispielsweise in der Programmiersprache Java) keine Garantie dafür, dass die Finalisierungsroutine von der automatischen Speicherbereinigung überhaupt aufgerufen wird.

In der Programmiersprache Java verfügen Objekte über eine spezielle Methode namens finalize(), die für diesen Zweck überschrieben werden kann. Aus den oben genannten Gründen wird für Java empfohlen, komplett auf Finalisierung zu verzichten und stattdessen eine explizite Terminierungsmethode zu verwenden.^[11] Der automatischen Speicherbereinigung fällt dann also ausschließlich die Aufgabe der Speicherverwaltung zu.

Einige ältere (APL, LISP, BASIC) und viele neuere Programmiersprachen verfügen über eine integrierte automatische Speicherbereinigung.

Für Programmiersprachen wie C, bei denen die Programmierer die Speicherverwaltung von Hand erledigen müssen, gibt es teilweise Bibliotheken, die eine automatische Speicherbereinigung zur Verfügung stellen, was bei der Programmierung aber leicht umgangen werden kann, beziehungsweise bei systemnaher Programmierung sogar umgangen werden muss. Aus diesem Grund können in einigen Programmiersprachen systemnah programmierte Module von der automatischen Speicherbereinigung ausgenommen werden, indem sie explizit gekennzeichnet werden (zum Beispiel in C# mit der Option /unsafe oder in Component Pascal mit der obligatorischen Anweisung IMPORT SYSTEM).

Weitere Beispiele für Programmiersprachen mit einer automatischen Speicherverwaltung sind Smalltalk, Haskell, Oberon, Python, Ruby, OCaml, Perl, Visual Objects, ABAP, Objective-C (ab Version 2.0), D sowie alle Sprachen, die auf der Java Virtual Machine (JVM) ablaufen (Java, Groovy, Clojure, Scala, …) sowie die für die Common Language Runtime von .NET entwickelt wurden (zum Beispiel C# oder VB.NET).

Apple führte 2007 mit der Veröffentlichung von Mac OS X Leopard (10.5) Garbage Collection als die „wichtigste Veränderung“ für Objective-C 2.0 ein, die gemäß Apple „Objective-C dieselbe Leichtigkeit der Speicherverwaltung wie bei anderen modernen Sprachen“ brachte.^[12] 2012 mit OS X Mountain Lion (10.8) wurde allerdings Garbage Collection als veraltet deklariert und die Verwendung des mit Mac OS X Lion (10.7) eingeführten automatischen Referenzzählungsmechanismus (engl. Automatic reference counting, ARC) zur Kompilierungszeit auf Basis des gerade eingeführten CLANG/LLVM 3.0 Compilers forciert.^[13] Bei dieser automatisierten Referenzzählung^[14] wird durch den Compiler Code zum Erkennen und Entfernen nicht mehr benötigter Objekten mittels Referenzzählung an geeigneten Stellen eingebaut.^[15] Im Gegensatz zu GCs mit Referenzzählung läuft die automatisierte Referenzzählung seriell und an zur Compilezeit festgelegten Zeitpunkten und damit deterministisch.^[16] Allerdings enthält ARC keine Möglichkeit, zyklische Referenzen zu erkennen; Programmierer müssen daher die Lebensdauer ihrer Objekte explizit managen und Zyklen manuell auflösen oder mit schwachen oder unsicheren Referenzen arbeiten.^[17]

Laut Apple haben Mobil-Apps ohne GC eine bessere und vorhersagbarere Leistungsfähigkeit.^[18][19] Das GC-freie iOS als Basis ermöglicht Apple, mobile Geräte mit weniger Speicher als die GC-basierende Konkurrenz zu bauen, welche trotzdem eine gleiche oder bessere Leistungsfähigkeit und Akku-Laufzeit aufweisen; ein Ansatz, der auch in der Fachpresse als architektonischer Vorteil beschrieben wurde.^[20][21][22]

• Richard Jones, Rafael Lins: Garbage Collection. Algorithms for automatic dynamic memory management. John Wiley, Chichester 1996, ISBN 0-471-94148-4.
• Richard Jones, Anthony Hosking, Eliot Moss: The Garbage Collection Handbook. The Art of Automatic Memory Menagement. (Chapman & Hall Applied algorithms and data structures series). CRC Press, Boca Raton, Fla. 2011, ISBN 978-1-4200-8279-1.

• Kai Jäger: Wie funktioniert der Java Garbage Collector? Software & Support Verlag GmbH, Mai 2009, archiviert vom Original am 13. Juni 2012; abgerufen am 28. Dezember 2015. 
• Wie funktioniert Garbage Collection? – JavaSPEKTRUM, Mai und Juli 2006 Klaus Kreft & Angelika Langer
• Benjamin Zorn: The Measured Cost of Garbage Collection. (PDF (404KiB)) UBC, Juli 1993, archiviert vom Original am 30. Mai 2009; abgerufen am 18. Mai 2011 (englisch).  (Alternativer Download: CiteSeerX)
• Garbage Collection im .NET Framework (englisch)
• Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning (englisch)
• A garbage collector for C and C++ (englisch)

1. ↑ Satish Chandra Gupta, Rajeev Palanki: Java memory leaks -- Catch me if you can. IBM DeveloperWorks, 16. August 2005, archiviert vom Original am 22. Juli 2012; abgerufen am 2. April 2015 (englisch). 
2. ↑ How to Fix Memory Leaks in Java (Memento vom 5. Februar 2014 im Internet Archive) von Veljko Krunic (10. März 2009)
3. ↑ Creating a memory leak with Java auf stackoverflow.com (englisch)
4. ↑ Microbenchmarking C++, C#, and Java: Object creation/destruction and method call. Dr. Dobb’s Journal, 1. Juli 2005, abgerufen am 11. April 2014. 
5. ↑ Arne Schäpers, Rudolf Huttary: Daniel Düsentrieb - C#, Java, C++ und Delphi im Effizienztest, Teil 2. c’t, Dezember 2003, S. 222–227, abgerufen am 26. Oktober 2009: „"Die Ergebnisse zeigen erstens, dass ein Garbage Collector (bei der Destruktion) vom Laufzeitverhalten her keine spürbaren Nachteile zu bringen scheint" und "Der teilweise schon fast doppelte Zeitbedarf von C++ bei der Konstruktion gegenüber den anderen Kandidaten..."“ 
6. ↑ Robert Hundt: Loop Recognition in C++/Java/Go/Scala. (PDF; 318 kB) Scala Days 2011, 27. April 2011, abgerufen am 17. November 2012 (englisch, Stanford, California): „Java shows a large GC component, but a good code performance. [...] We find that in regards to performance, C++ wins out by a large margin. [...] The Java version was probably the simplest to implement, but the hardest to analyze for performance. Specifically the effects around garbage collection were complicated and very hard to tune“ 
7. ↑ Matthew Hertz, Emery D. Berger: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management. OOPSLA 2005, 2005, abgerufen am 15. März 2015 (englisch): „In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower.“ 
8. ↑ Benjamin Zorn: The Measured Cost of Conservative Garbage Collection. Department of Computer Science, University of Colorado Boulder, 22. Januar 1993, abgerufen am 18. November 2012 (englisch): „Conservative garbage collection does not come without a cost. In the programs measured, the garbage collection algorithm used 30–150 per cent more address space than the most space efficient explicit management algorithm. In addition, the conservative garbage collection algorithm significantly reduced the reference locality of the programs, greatly increasing the page fault rate and cache miss rate of the applications for a large range of cache and memory sizes. This result suggests that not only does the conservative garbage collection algorithm increase the size of the address space, but also frequently references the entire space it requires.“ 
9. ↑ Constant-Time Root Scanning for Deterministic Garbage Collection (PDF; 375 kB): Garbage Collection [...] typically brings a high degree of indeterminism to the execution environment.
10. ↑ Garbage Collection für Parallele und Verteilte Systeme, Frank Joachim Frey, 7. Mai 2002
11. ↑ Josuah Bloch: Effective Java, S. 31: Avoid Finalizers
12. ↑ Objective-C 2.0 Overview (Memento vom 24. Juli 2010 im Internet Archive)
13. ↑ Mac OS X 10.7 Lion: the Ars Technica review John Siracusa (20. Juli 2011)
14. ↑ Rob Napier, Mugunth Kumar: iOS 6 Programming Pushing the Limit. John Wiley & Sons, 20. November 2012, abgerufen am 30. März 2015 (englisch): „"ARC is not garbage collection [...] this makes the code behave the way the programmer intended it to but without an extra garbage collection step. Memory is reclaimed faster than with garbage collection and decision are done at compile time rather than at run-time, which generally improves overall performance."“ 
15. ↑ Memory Management
16. ↑ ARC vs. GC
17. ↑ The Clang Team: AutomaticReferenceCounting. In: Clang 3.7. Documentation. Abgerufen am 31. Mai 2015 (englisch): „It does not provide a cycle collector; users must explicitly manage the lifetime of their objects, breaking cycles manually or with weak or unsafe references.“ 
18. ↑ Developer Tools Kickoff - session 300. In: WWDC 2011. Apple, Inc., 24. Juni 2011, abgerufen am 27. März 2015 (englisch): „“At the top of your wishlist of things we could do for you is bringing garbage collection to iOS. And that is exactly what we are not going to do… Unfortunately garbage collection has a suboptimal impact on performance. Garbage can build up in your applications and increase the high water mark of your memory usage. And the collector tends to kick in at undeterministic times which can lead to very high CPU usage and stutters in the user experience. And that’s why GC has not been acceptable to us on our mobile platforms. In comparison, manual memory management with retain/release is harder to learn, and quite frankly it’s a bit of a pain in the ass. But it produces better and more predictable performance, and that’s why we have chosen it as the basis of our memory management strategy. Because out there in the real world, high performance and stutter-free user experiences are what matters to our users.”“ 
19. ↑ José R.C. Cruz: Automatic Reference Counting on iOS. Dr. Dobbs, 22. Mai 2012, archiviert vom Original (nicht mehr online verfügbar) am 16. August 2012; abgerufen am 30. März 2015 (englisch): „“Finally, the [Garbage collection] service still incurs a performance hit despite being conservative. This is one reason why garbage collection is absent on iOS.[…] ARC is an innovative approach that has many of the benefits of garbage collection, but without the performance costs. Internally, ARC is not a runtime service. It is, in fact, a deterministic two-part phase provided by the new Clang front-end.”“  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.drdobbs.com 
20. ↑ Felix Disselhoff: Nur 1 GB RAM?! Warum das iPhone 6 die Androiden abhängt. curved.de, 17. November 2014, abgerufen am 22. September 2018: „Warum ist das iPhone mit nur 1 GB RAM schneller als die Android-Konkurrenz mit 2 oder 3 GB RAM? Die Erklärung ist einfach und hat mit “Müll” zu tun. […] Android braucht das Vielfache des verwendeten Speichers“ 
21. ↑ Oliver Haslam: Why iPhone With 1GB RAM Performs Better Than Android Devices With 2GB Or More RAM? redmondpie.com, 16. November 2014, abgerufen am 25. März 2015. 
22. ↑ Precious Silva: iOS 8 vs Android 5.0 Lollipop: Apple Kills Google with Memory Efficiency. International Business Times, 18. November 2014, archiviert vom Original (nicht mehr online verfügbar) am 3. April 2015; abgerufen am 7. April 2015 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/au.ibtimes.com