Copying Garbage Collection

Transkript

1 opying Garbage ollection Guido Tack März 2002 Zusammenfassung opying Garbage ollection ist eine einfache, aber effiziente Methode zur automatischen Speicherverwaltung. In dieser usarbeitung im Rahmen des Seminars Garbage ollection im Wintersemester 2001/2002 wird die grundlege Idee hinter opying Garbage ollection beschrieben, heneys lgorithmus (der wichtigste weil effizienteste opying-lgorithmus) im etail erklärt sowie auf Vor- und Nachteile und Einsatzgebiete von opying Garbage ollection eingegangen. bschließ wird das Verhältnis von opying Garbage ollection zu anderen, moderneren Methoden erläutert. 1 Einleitung In dieser usarbeitung wird opying Garbage ollection vorgestellt, eine Methode zur automatischen Speicherbereinigung (Garbage collection, im Folgen durch G abgekürzt). opying G ist eine schon sehr alte Strategie zur Speicherverwaltung, die erste Implementierung stammt von Marvin Minsky aus dem Jahr 1963; Minsky implementierte einen opying Garbage ollector in Lisp 1.5 (siehe [9]). Trotzdem ist sie auch heute noch aktuell, entweder in ihrer Reinform oder als Grundlage modernerer lgorithmen. iese usarbeitung ist wie folgt gegliedert: Im bschnitt 2 wird die grundsätzliche Idee beschrieben, die hinter opying G steht. bschnitt 3 stellt den wichtigsten und grundlegen lgorithmus in diesem ereich vor. bschnitt 4 beschäftigt sich mit den Nachteilen, bschnitt 5 mit Variationen von opying G. Im 6. bschnitt wird diskutiert, wie die Effizienz des lgorithmus gesteigert werden kann, und bschnitt 7 zeigt die möglichen Einsatzgebiete von opying G auf. bschließ gibt bschnitt 8 einen usblick und eine Zusammenfassung. 2 ie Idee hinter opying G opying G teilt den logischen Speicher in zwei sogenannte Semi-Spaces auf: den -Space und den -Space. Zu jeder Zeit ist nur einer der beiden Speicherbereiche aktiv, nämlich der -Space. 1

2 ktiv bedeutet in diesem Zusammenhang: lle Operationen des Mutators arbeiten nur in diesem Speicherbereich, alle lebigen Zeiger zeigen nur in diesen ereich, und neuer Speicher wird nur in diesem ereich allokiert. Wenn die G angestoßen wird (üblicherweise, wenn kein Speicher mehr allokiert werden kann), werden alle lebigen Objekte aus dem -Space in den -Space kopiert und dann die Rollen der beiden ereiche vertauscht. abei müssen selbstverständlich alle Zeiger auf die kopierten Objekte umgeleitet werden. bbildung 1 zeigt exemplarisch den Zustand vor und nach dem Kopieren der Objekte. urch das anschließe Vertauschen der Rollen wird der -Space zum neuen -Space; das heißt, dass sowohl die ehemals lebigen Objekte als auch der Müll darin beim nächsten Kopiervorgang überschrieben werden. Insofern ist opying G eigentlich kein Garbage ollector, sondern eher ein Live Nodes ollector 1. Minsky s ollector benutzte die oben genannte ufteilung in Semi-Spaces noch nicht, sondern kopierte die lebigen Objekte in eine atei auf einem andlaufwerk, um sie von dort wieder linear in den Speicher einzulesen. ie Idee der Semi-Spaces im Speicher wurde von Robert Fenichel und Jerome Yochelson im Jahr 1969 in [6] beschrieben. Ihre Implementierung kopierte rekursiv die Objekte aus dem -Space in den -Space. Garbage Garbage bbildung 1: Vor und nach dem Kopieren bbildung 1 illustriert auch gleich einen großen Vorteil von opying G : Nach dem Kopieren liegen die Objekte linear und kompakt im -Space, opying G vermeidet also eine Fragmentierung des freien Speichers. Ein weiterer Vorteil ist die effiziente llokation von neuem Speicher, sie erfolgt einfach linear, beginn hinter dem letzten Objekt im -Space. 1 Ein solcher ollector wird auch oft Scavenger genannt. 2

3 3 heneys lgorithmus 3.1 Motivation ie naive Implementierung des oben beschriebenen lgorithmus würde den Graph der lebigen Objekte rekursiv durchsuchen und in den -Space kopieren. heney beschreibt in [5] einen lgorithmus, der im Gegensatz dazu iterativ arbeitet und deshalb nur konstanten Laufzeit-Stack benötigt. heneys lgorithmus ist die effizienteste Implementierung von opying G. 3.2 heneys nsatz reitensuche Um heneys lgorithmus zu verstehen, betrachten wir zunächst einen einfachen lgorithmus für reitensuche (breadth first search) in einem Graphen (bbildung 2). ieser durchmustert den gesamten Graphen, wobei er jeden Knoten nur einmal in die Queue einträgt. ie Laufzeit ist offensichtlich linear in der nzahl der Knoten. q = new queue for x in root set do q.pushack(x) x.marksseen while not q.isempty do d = q.popfront for x in d.children do if x.notyetseen then q.pushack(x) x.marksseen a) Pseudocode b) Illustration (Nummern geben die Reihenfolge der Exploration an) bbildung 2: reitensuche Eine Queue im -Space heneys Idee war jetzt, den -Space als Queue-atenstruktur zu nutzen. azu benötigt man zwei Zeiger, im Folgen und genannt, die beide in den -Space zeigen. 3

4 zeigt hinter das letzte kopierte Object und repräsentiert das Ende der Queue. zeigt auf das nächste zu ne Objekt und stellt den nfang der Queue dar. (Siehe bbildung 3; dort ist der Graph aus bbildung 1 zu sehen, von dem schon die Objekte, und in den -Space kopiert wurden. ist schon wieder aus der Queue entfernt und somit vollständig abgearbeitet.) bbildung 3: und, Forwarding Pointers (er Graph entspricht dem aus bbildung 1, einige Zeiger wurden durch Forwarding Pointer überschrieben: In Objekt wurde z.. der Zeiger auf mit überschrieben.) ie eschreibung des lgorithmus ist jetzt einfach: q.pushack entspricht dem Kopieren des Objekts in den -Space mit anschließem Verschieben von hinter das Ende des Objekts. q.popfront entspricht dem uslesen des Objekts an Position mit anschließem Verschieben von auf das nächste Objekt. q.isempty ist äquivalent zu =. (as bedeutet insbesondere, dass der lgorithmus terminiert, wenn sich und treffen.) Forwarding Pointers Ein wichtiger spekt muss aber noch berücksichtigt werden: ie Zeiger innerhalb der Objekte müssen entsprech auf die Kopien umgeleitet werden. er erste Fall ist dabei einfach: Wenn der lgorithmus ein Objekt erreicht und kopiert, schreibt er den Zeiger, über den das Objekt erreicht wurde, auf die neue dresse um (dieser Fall trifft auch auf Zeiger aus dem Root-Set zu). Etwas schwieriger wird es beim zweiten Fall: Was passiert, wenn ein schon kopiertes Objekt nochmal über einen Zeiger erreicht wird? In diesem Fall bedient man sich sogenannter Forwarding Pointer. Sobald ein Objekt kopiert wird, wird zum eispiel im ersten Feld des Original-Objektes die neue dresse hinterlegt. Wenn dieses Objekt jetzt nochmal erreicht wird, merkt der lgorithmus, dass es sich um ein schon kopiertes 4

5 Objekt handelt und kann den Zeiger, über den das Objekt erreicht wurde, entsprech umleiten (siehe ebenfalls bbildung 3) llokation ie llokation von neuem Speicher zwischen zwei G -Zyklen erfolgt linear, hierzu kann benutzt werden (der ja, nach Vertauschen der Rollen, jetzt im -Space liegt). Neuer Speicher wird dann allokiert, indem der aktuelle als nfang des Speicher-lockes zurückgegeben und dann hinter das Ende des lockes verschoben wird. er vollständige lgorithmus ist in bbildung 4, eine Illustration seiner Vorgehensweise in bbildung 5 zu sehen. 2 In der arstellung werden die Objekte in drei Farben dargestellt: Weiße Objekte gelten nach der Garbage ollection als Müll, graue Objekte wurden schon kopiert, aber noch nicht vollständig bearbeitet, bei schwarzen Objekten ist die earbeitung abgeschlossen. Konkret heißt das, dass alle Objekte im -Space weiß sind (und bleiben), in den -Space kopierte Objekte sind zuerst grau, und wenn über sie hinweggelaufen ist werden sie schwarz. Somit sind am Ende der G (wenn = ) alle lebigen Objekte schwarz. //q = new queue new = new pointer for x in root set do //pushack(x) copy(x, ) setforwardingpointer(x, ) x.marksseen +=sizeof(x) while not = do d = objectt( ) //q.popfront for x in d.children do if x.notyetseen then //q.pushack(c) copy(x, ) setforwardingpointer(x, ) new = x.marksseen +=sizeof(x) else new = getforwardingpointer(x) update(c.child(x), new) bbildung 4: heneys lgorithmus, Pseudocode 3.3 Voraussetzungen für den lgorithmus heneys lgorithmus macht folge Voraussetzungen über ufbau und Eigenschaften der behandelten Objekte: ie Größe eines Objekts muss bekannt sein, um und entsprech inkrementieren zu können. Zu jedem Objekt muss bekannt sein, wie man dessen Kinder erreicht, also wo im Objekt Zeiger auf andere Objekte stehen. 2 Eine animierte arstellung der Vorgehensweise des lgorithmus findet man in [11]. 5

6 bbildung 5: heneys lgorithmus, illustriertes eispiel (Nach dem 6. Schritt folgt noch die Vertauschung der Rollen von -Space und -Space.) 6

7 Objekte müssen als schon gesehen markiert werden können. Man benötigt zwei logisch zusammenhänge Speicher-löcke. ie letzte nnahme kann man insofern aufweichen, als dass man den lgorithmus relativ leicht so anpassen kann, dass er eine Kette von - und -Spaces benutzt (siehe bbildung 6). Spaces Spaces bbildung 6: Kette von Speicherblöcken 3.4 Eigenschaften des lgorithmus heneys lgorithmus hat einige wichtige Eigenschaften, die ihn interessant machen. Sie wurden teilweise schon oben erwähnt und sollen hier noch einmal zusammengefasst werden: ie wichtigste Eigenschaft von heneys lgorithmus ist der Speicherverbrauch: Es wird nur konstanter Speicher auf dem Stack benötigt. iese Eigenschaft ist es, die den lgorithmus so effizient macht und die auch zu seiner Verbreitung beigetragen hat. ie Laufzeit beträgt O(l), wenn l die nzahl der lebigen Objekte ist, da nur diese vom lgorithmus betrachtet werden 3. Zyklische atenstrukturen sowie Sharing 4 werden korrekt behandelt (mittels Forwarding Pointers). as heißt, dass bei der G die gesamte Struktur des Graphen in den -Space kopiert wird, Zykel und Sharing also erhalten bleiben. er freie Speicher ist nach der G kompakt, es tritt also keine Fragmentierung auf. heneys ollector ist ein Stop/Start-ollector, der Mutator muss also für die G angehalten werden. Zwischen zwei G -Zyklen ist dafür aber keine weitere rbeit zu leisten, insbesondere sind keine Lese- oder Schreibbarrieren nötig. 4 Nachteile der opying G 4.1 uf hoher Ebene ie Laufzeit von opying G hängt nicht nur von der nzahl der lebigen Objekte, sondern auch von deren Größe ab. Währ es bei kleinen Objekten keinen nennenswerten Unterschied macht, ob man sie nur markiert oder kopiert, kann das bei großen Objekten stark ins Gewicht 3 In [1] wird beschrieben, dass in SML/NJ währ der G nur etwa 2% der Objekte überleben; diese Eigenschaft trägt also stark zur Effizienz bei. 4 Sharing bedeutet, dass mehrere Zeiger auf dasselbe Objekt verweisen 7

8 fallen. Insbesondere für große, langlebige Objekte (die folglich oft kopiert werden müssen) ist opying G also nicht optimal. Ein weiterer Nachteil kann sein, dass die doppelte Menge an logischem Speicher nötig ist. as stellt auf modernen Rechnern dank virtuellem Speicher kein größeres Problem dar, kann aber evtl. bei kleinen rchitekturen wie zum eispiel Handhelds gegen opying G sprechen (siehe zum eispiel [3]). 4.2 uf niedriger Ebene ie reitensuche, die zum espiel in heneys lgorithmus benutzt wird, führt dazu, dass Objekte, die zuvor nahe beieinander im Speicher lagen, nach der G weit voneinander entfernt liegen können. ie sogenannte Lokalität wird also zerstört. Man kann annehmen, dass logisch, also vom Programmfluss her zusammenhänge Objekte kurz hintereinander erzeugt werden und deshalb (wegen der linearen llokation) nahe zusammen im Speicher liegen (siehe [7]). Wenn jetzt also nach der G wieder auf diese Objekte zugegriffen wird, liegen sie weit auseinander, so dass ache misses oder sogar Page faults auftreten können, die zu Performanz-Einbußen führen. iese spekte sind aber so stark von der Implementierung und der rchitektur, auf der diese laufen soll, abhängig, dass hier nicht weiter darauf eingegangen wird. 5 Variationen usgeh von den im vorigen bschnitt vorgestellten Nachteilen könnte man folge Variationen in etracht ziehen: 1. Spezielle ehandlung großer Objekte (Large Object reas). Große Objekte werden aus dem Zuständigkeitsbereich des opying Garbage ollectors herausgenommen und separat, mit einer anderen G -Strategie, behandelt (siehe [4], [13]). 2. ereiche langlebiger Objekte Objekte, von denen festgestellt werden kann, dass sie eine lange Lebenszeit haben, werden in speziellen ereichen gespeichert. Ihre Zeiger werden zwar gent (um andere lebige Objekte zu finden), sie werden aber nie kopiert. 3. eibehaltung der Lokalität durch andere Explorations-Strategien Tiefensuche (epth first search) hat die Eigenschaft, Lokalität zu bewahren. Es gibt einige nsätze, andere Explorationsstrategien, die der Tiefensuche ähnlich sind, zu benutzen, aber dabei ist es immer sehr schwierig, trotzdem mit konstantem Laufzeit-Stack auszukommen. Ohne die Eigenschaft kann man den lgorithmus nicht mehr als effizient betrachten. Einige eispiele kann man in [8] finden, genauere Informationen zum eispiel in [10] oder [12]. esonders der Punkt 2 ist dabei interessant. ie Forschung auf diesem ereich führte zur Entwicklung der generationalen G, bei dem unterschiedlich alte Objekte (Objekte verschiedener 8

9 Generationen) unterschiedlich behandelt werden. 6 Verbesserung der Effizienz Hier soll eine relativ einfache Möglichkeit vorgestellt werden, die Effizienz eines opying Garbage ollectors zu verbessern. Eine erste eobachtung (die eigentlich trivial ist) besagt, dass die Häufigkeit, mit der der Garbage ollector aufgerufen wird, abnimmt, wenn die Semi-Spaces größer sind. abei spielt aber noch eine weitere Tatsache eine Rolle: Üblicherweise ist der Speicherplatzbedarf der lebigen Objekte über die Laufzeit des Programmes relativ konstant. as heißt aber, dass der Garbage ollector, obwohl er seltener aufgerufen wird, die gleiche Menge an lebigen Objekten kopieren muss (siehe bbildung 7). Mehr noch: Je seltener die Garbage ollection einsetzt, desto älter werden die Objekte. Es ist also wahrscheinlich, dass bei größeren Semi-Spaces zum Zeitpunkt der G sogar weniger Objekte lebig sind. ies alles ist natürlich nur relevant, weil die Laufzeit von opying G nur von der nzahl der lebigen Objekte abhängt. Theoretisch lässt sich die Effizienz auf diesem Weg beliebig steigern, wie in [2] beschrieben wird. ie Vergrößerung der Semi-Spaces ist aber selbstverständlich nur dann sinnvoll, wenn sie innerhalb des physikalisch verfügbaren Speichers passiert. Ein uslagern eines Semi-Spaces auf Festplatte zum eispiel hätte katastrophale uswirkungen auf die Laufzeit. 7 Einsatzgebiete von opying G Wann ist es also sinnvoll, einen opying Garbage ollector einzusetzen? Hier lassen sich drei Kriterien identifizieren: 1. ie Speicherverwaltung wird von llokation dominiert. ei Systemen mit dieser Eigenschaft kann opying G große Vorteile gegenüber anderen Verfahren bieten, da llokation extrem billig ist. 2. Es gibt viele kleine, kurzlebige Objekte. Hier kann opying G punkten, da nur lebige Objekte behandelt werden. ußerdem ist das Kopieren kleiner Objekte fast genauso teuer wie das Markieren (zum eispiel also im Vergleich zu mark-sweep). 3. ie Verzögerung durch G spielt keine Rolle. Echtzeit-Systeme sind also kein typisches nwungsbeispiel für einen klassischen opying Garbage ollector. 9

10 2x3 M 3 M 2 M 2 M 2 M 2 M 2 M 13 M llokation 2x6 M 6 M 2 M 5 M bbildung 7: Effizienzsteigerung durch größere Semi-Spaces 8 Zusammenfassung und usblick opying G ist eine effiziente Methode, um eine automatische Speicherverwaltung zu implementieren. heneys lgorithmus ist die effizienteste Implementierung von opying G ; effizient wird sie dadurch, dass nur konstanter Stack zur Laufzeit benötigt wird und die Laufzeit der G nur von der nzahl der lebigen Objekte abhängt. Es wurde gezeigt, wie die Laufzeit von opying G von dem Parameter der Größe der Semi-Spaces abhängt. ußerdem wurden Probleme behandelt, die durch opying G auftreten, insbesondere was große Objekte und Lokalität angeht. bschließ wurde eine ewertung gegeben, in welchen Zusammenhang die enutzung eines Garbage ollectors mit opying sinnvoll sein kann und wo eher nicht. ie Idee, große Objekte getrennt zu behandeln, führt zur Entwicklung von hybriden Systemen, in denen ein Teil der G von einem opying ollector gemacht wird, ein anderer Teil aber zum eispiel von Mark-Sweep oder Mark-ompact. ls usblick sollte noch erwähnt werden, dass opying G die asis für viele andere G - Verfahren bildet: sowohl generationale als auch inkrementelle Verfahren bauen oft auf opying auf. 10

11 Literatur [1] ndrew W. ppel. ompilers and runtime systems for languages with garbage collection. [2] ndrew W. ppel. Garbage collection can be faster than stack allocation. Information Processing Letters, 25(4): , [3] Fred ayer, LispMe (Scheme for the Palm Pilot), hood.htm#gc. [4] Patrick J. audill and llen Wirfs-rock. third-generation Smalltalk-80 implementation. pages [5]. J. heney. non-recursive list compacting algorithm. ommunications of the M, 13(11):677 8, November [6] Robert R. Fenichel and Jerome. Yochelson. Lisp garbage collector for virtual memory computer systems. ommunications of the M, 12(11): , November [7] arry Hayes. Using key object opportunism to collect old objects. pages [8] Richard E. Jones and Rafael. Lins. Garbage ollection: lgorithms for utomatic ynamic Memory Management. John Wiley & Sons, New York, [9] Marvin L. Minsky. Lisp garbage collector algorithm using serial secondary storage. Technical Report Memo 58 (rev.), Project M, MIT, ambridge, M, ecember [10] avid. Moon. Garbage collection in a large LISP system. pages [11] Guido Tack, opying G, Seminar-Folien, gc.pdf. [12] Stephen P. Thomas and Richard E. Jones. Garbage collection for shared environment closure reducers. Technical Report 31 94, University of Kent and University of Nottingham, ecember [13] avid M. Ungar and Frank Jackson. Tenuring policies for generation-based storage reclamation. 23(11):1 17,