VM Memory Management Thomas Nguyen 13.05.2009

VM Memory Management Was ist Memory Management? Was hat Garbage Collection mit Memory Management zu tun? Wie funktioniert ein Garbage Collector?

Memory Management? Heikle Sache – nicht ungefährlich! Speicher ist begrenzt Lebenszyklus von Java Objekten Speicher zuordnen (allokieren) Speicher freigeben (deallokieren) Neue Objekte Speicher zuordnen Ungenutze Objekte löschen Bei einem dangling Pointer handelt es sich um einen Zeiger, der auf ein Objekt verweist, welches bereits freigegeben ist. Speicherleck Prozess einen Speicherbereich belegt, diesen jedoch im Zuge der Ausführung weder freigeben noch nutzen kann. Heikle Sache – nicht ungefährlich!

Architektur der Java-VM Wenn die die JVM ausgeführt wird, werden für viele Sachen Speicherplatz benötigt. zB. Der Bytecode an sich , rückgabewerte, lokale variablen, Methodenparameter, usw… In der JVM werden diese in verschiedene Laufzeit Daten Bereiche geteilt. Die Spezifikation der Runtime Data ist für die JVM nur abstract beschrieben. Eine Konkrete Implementierung, ist jedem Designer selbst überlassen. Quelle: http://www.artima.com/insidejvm/ed2/jvm2.html

Architektur der Java VM Method Area CLASS A Constant Pool Fields Methods Attributes Class B Class A Klasseninformationen: Runtime Constant Pool: Numerishe Konstanten String Konstanten Felder: Modifier Methoden: implementierung der Methoden: name rückgabewert, bytecode

Architektur der Java-VM Java VM – STACKS STACK FRAME 3… STACK FRAME 2 STACK FRAME 1 Eigene Datenstruktur der JVM Stack für jeden Thread: Frame: für jeden Block (Methode) Lokale Variablen einer Methode Int, float, oder referenzen auf ein Objekt Auf dem Operanden-Stack werden die Befehle der JVM ausgefürt. Das macht die JVM zur Stack-Maschine. Enthält einen Referenz auf den Runtime Constant Pool der Klasse dessen Methode aufgerufen wurde. Diese Referenz wird verwendet, um dynamisches Binden von Methoden und Feldern (Variablen) zu realisieren. STACK FRAME 1 Lokale Variablen Operanden Stack RCP Referenz

HEAP Dynamischer Speicher Mit „New“ angelegte JAVA Objekte liegen hier New“ reserviert den benötigten Speicherplatz, Adresse wird als Referenz zurückgegeben Sind über Referenzen zugänglich (auf dem Stack) Zusammenhängender Speicherbereich Speicher ist ein Array von Bytes mit Adressen Um weiterzumachen und über die verborgenen Datenstrukturen zu reden, möchte ich euch eine ganz kurze Einführung zum Speicheraufbau geben. Ein grobes verständnis wird benötigt um zu verstehen, was unter der Haube von der JVM läuft. Etwas was Java vor uns versteckt, ist dass Speicher ein einziges Großes Array ist. Ein Array aus Bytes mit Indexen, gennat Adressen. Man kann sich das wie auf der Abb. Vorstellen. Normalerweise lesen und schreiben Computer 4 Bytes auf einmal. Daher können wir den Anfang einer Adresse, als jedes 4te Byte ansehen. Wenn wir eine LoKale Variable anlegen,dann weisen wir diesem indirekt eine Speicheradresse zu. Int x, dann haben wir eine Speicherplatz gennat x, Für uns heißt die Adresse X, java holt sich eine entsprechende adresse für uns. Wir müssen uns keine gedanken mehr darübe rmachen. kann eine statisch Größe haben, oder zwischen einer minimalen und einer maximalen Größe variieren (diese dürfen sich auch beim Start der JVM vom Anwender über Parameter festgelegen lassen). Dadurch unterscheidet er sich von der anderen Speicherdatenstruktur, dem „Stack“ (Kellerspeicher). Im Stack werden Daten von lokalen Variablen abgelegt, deren Speicherbedarf bereits bei der Programmübersetzung bekannt ist. Ausserdem wird der Speicher automatisch wieder freigegeben, sobald der Gültigkeitsbereich der lokalen Variablen verlassen wird. Der Heapspeicher bietet also zusätzliche Flexibilität, die aber ihren Preis hat: Es gibt keinen Mechanismus und keine Regeln, wie und wann der belegte Speicherplatz wieder freigegeben wird. Keine Suche nach freiem Speicher Bump a pointer e n t w i c k e l t s i c h u n g e o r d n e t i P r o g r a m m a b l a u f Local variables live on the stack – Allocated at method invocation time – Deallocated when method returns … 1 2 3 4 5 6 7

Runtime Data Area´s HEAP … Method Area MyObject object1; object1 = new MyObject(); … STACK ptr to class data ptr to class data information information Object reference instance data ptr into heap … instance data ptr to class data information instance data Bump pointer Free list Two machine word The first header word is a reference to the object's class. The second, contains other information, such as the identity hash code, and garbage collection status information Die Method area -darstellung der implementirung einer klasse RCP (Runtime Constant Pool) Felder Methoden attribute The first header word contains information such as the identity hash code and garbage collector status information. The second is a reference to the object's class. Only arrays have a third header field, for the array size. Class Myobject Extends java/lang/object toString(); hashCode() Method Area Class Data MyObject Class Data

Fast Allocation Bump Pointer … … STACK HEAP MyObject object; object = new MyObject; … Nächste freie Speicheradresse Allocation : update a single pointer … … STACK object …

Architektur der Java-VM PC Register: Program Counter Jeder Thread hat ein eigenenes PC-Register und führt immer eine Methode zur Zeit aus can hold both a native pointer and a returnAddress Quelle: http://www.artima.com/insidejvm/ed2/jvm2.html

Garbage Collection? Garbage Collection ist ein Begriff für die automatisierte Speicherverwaltung (Freispeicherverwaltung) Garbage Collector versucht Garbage (Müll) zu entsorgen Garbage = Objekte, die nicht mehr vom Programm benötigt werden Aber wie ist er denn nun – der GC, das unbekannte Wesen? Das ist gar nicht so einfach zu sagen. SUN verlangt zwar, dass jede JVM einen GC haben muss. Aber die Java Virtual Machine Specification legt nicht fest, nach welchem Algorithmus er arbeiten, und welche Strategie er verfolgen soll. Man wollte sich nicht verbauen, zukünftige Entwicklungen der Speicherforschung in neue JVMs aufnehmen zu können. Das war sehr klug. Wie die Entwicklung der JDKs zeigt, war wohl auch SUN davon überrascht, wie viel Missbrauch die Entwickler mit ihrem Speicher und dem GC treiben würden. So wurde mit dem JDK 1.3 eine radikale Änderung am GC eingeführt, welche die Leistung der JVM bei Lasten mit vielen kurzlebigen Objekten deutlich verbessern konnte. Dazu später mehr. Eine JVM ist für das Gastsystem ein Prozess. Sie wird wie jedes gewöhnliche Programm gestartet, und benötigt zum Arbeiten Speicher. Den holt sie sich dynamisch vom Betriebssystem. Aus diesem Speicher macht sie den Heap, die Stacks (für jeden Ihrer Threads einen), den Speicher für die Bytecodes, und natürlich auch noch den Speicher zum Verwalten der ganzen Veranstaltung. The JVM Specification doesn’t say how to manage the heap • Simplest valid memory management strategy: never delete any objects – Not such a bad idea in some circumstances (when?)

Garbage Collection JVM hat das Rad nicht neu erfunden Findet auch Anwendung bei vielen andern Sprachen Lisp (1959) Smalltalk Scheme Objective C C# … Die haben z.b Biliotheken, die einem dann die speicherverwaltung dann abnehmen

Vor- und Nachteile einer Garbage Collection Vorteile: Erhöhte Zuverlässigkeit Entkopplung der Speicherverwaltung vom Klassen- und Interface Design Keine Entwicklungszeit um Memory Management Fehler aufzuspüren!!! Nachteile: CPU Zeit Overhead Pausen Sie können mit System.gc() den GC niemals direkt aufrufen. Sie beantragen nur eine Garbage Collection Anwendungen: für die sind die nachteile tötlich;

Anforderungen an eine Garbage Collection (SUN) safe and comprehensive efficiently without introducing long pauses limitation of fragmentation scalability Sicher und vollständig d.h. lebende objekte dürfen nicht fälsherweise entfernt werden und Garbage darf nicht übrig gelassen werden. Fast fast allocation fast, promt reclaimation, minimal distruption of running program Allocation should not become a scalability bottleneck for multithreaded applications on multiprocessor systems, and collection should also not be such a bottleneck.

GARBAGE COLLECTION Grundlagen Java virtual machine (JVM) hat verborgene Datenstrukturen, um Speicher zu verwalten Root: Referenzen, auf die ein Programm direkten Zugriff hat lokale Variablen auf einem Stack static Variablen Was ist garbage collection java bereinigt garbage für uns, was einige andere sprachen nicht machen.das kann sich bei der produktivität bemerktbar machen Was ist garbage collection? Objekte verbrauchen Speicher. Man kann einen batzen Objekte Speicher zuweisen und dann kann es passieren, dass man diese einfach vergisst uns nicht mehr darauf zugreift. Der Speicher ist aber für diese Objekte verbraucht, aber wäre es nicht besser den Speicher für andere oder neue Sachen zu verwenden. In c++ kann der programmierer explizit sagen, ok hier der speicher kann für neue objekte benutzt werden. In Java hingegen, wird dies von Java gemacht. Wie macht das Java? Java benutzt einige Algorithmen die ich euch heute gerne vorstellen möchte. Java, Die Java virtual machine, die unseren compilierten bytecode ausführt, hat verborgene datenstrukturen, die dem programmieren nicht ersichtlicht sind. Wir können mit unserem java programm darauf nicht direkt zugreifen. Aber die sind dafür da, dass java feststellen kann, welche objekte nocht benutzt werden und welche garbage sind und recyclet werden können um den speicher wiederverwenden zu können. Die Datenstrukturen sind zwar vor uns verborgen, aber es kann nützlich sein im Kopf eine Vorstellung über das Speichermodell von Java zu haben, und zu wissen, wann java objekte recylcen kann und wann nicht. Es könnte uns dabei helfen, programme zu schreiben, die für die jvm einfacher ist garbage collection durchzuführen, und dadurch unsere programme effizienter werden. Zwar braucht man sich keine gedanken über garbage collection zu machen, aber es kann mal vorkommen, dass ihr große programme mit vielen objekten schreibt, und um ein out of memory vorzubeugen, kann dies nützlich sein. In Java beginnt die Garbage Collection bei den Roots Hauptdirektive bei java: Nie ein Objekt entsorgen, die wir noch möglicherwiese brauchen. Also in java dürfen grundlegend NIE Live Objekte gelöscht werden. Gegenteil von live ist garbage. Garbage sind objekte die unser programm nicht mehr referenzieren kann, also kein zugriff mehr darauf erlangen kann. Javas Desgin macht es nun möglich feststellen zu könne ob ein Objekt erreichbar.

Objekte: live & garbage Ein Objekt, welches unser Programm möglicherweise noch braucht, nennt sich „lebend“ Gegenteil von lebend ist garbage, Objekte die unser Programm nicht mehr referenzieren kann Objekt ist „lebend“ wenn, eine Referenz durch ein Root besteht, oder es eine Referenz durch ein anderes lebendes Objekt hat es vom Root aus erreichbar ist Root ist eine Variable auf die wir direkt zugreifen können. Direkt heißt, ohne umwege über andere Referenzen. Es gibt verschiedene Arten von Roots. Lokale Variablen auf einem Stackframe Klassen variablen, sind diejenigen, die wir static deklarieren. Wenn Klassenvariablen Referenzen darstellen, dann sind diese auch Roots. Ein Objekte ist Live, wenn es von einem Root referenziert ist, oder durhc ein anderes LIVE Objekt. Das Problem bei diese Defintion ist, es ist Recursiv. Wenn sich 2 Live Objekte gegenseitig referenzieren, dann hat man ein Problem Man kann sich das so vorstellen, als wären alle Objekte ein Knoten in einem Graphen. Wenn ein Objekt vom erreichbar sein soll, dann muss es einen weg von der wurzel aus gegen, womit man das Okjekt im Graphen erreichen kann.

Erreichbarkeit von Objekten Durchlaufe eine DFS (Tiefensuche) vom Root Jedes Objekt hat ein „visited“ tag ROOT RUN DFS vom Root. Für das DFS benötigt jedes Objekt ein „visited „ Tag. Das ist eins von den Sachen die Java vor uns verborgen hält.

Mark & Sweep Garbage Collection 2 Phasen: Mark Phase Startet DFS von jedem Root aus und markiert lebende Objekte Sweep Phase Speicher wird von nicht markierten Objekten freigegeben Ein Mark & Sweep Collector läuft in 2 Phasen Mark Phase Und Sweep Phase Mark Phase…, Wenn Java die Mark Phase startet dann wird unser Programm angehalten. Nach der Mark Phase, bleiben nichtmarkierte Objekte über. Diese sind dann Garbage JVM hat datenstrukturen die freien und zugeweisenen speicher verwaltet. Ähnlich einem AR auf einem Stack repäsetiern eine Datrenstruktur, die die JVM lesen kann Um zu schauen was alles ein root ist. So kann es mark phase starten Sweep phase: Hinzufügen der unmarkierten Speicherbereiche zu einer Freispeicherliste Nach einem Mark & Sweep wird eine Compaction ausgeführt. Es ist ein Problem ist Fragmentierung ROOT

Compaction Fragmentierung: Freier Speicher hat die Tendenz sich in viele kleine Bereiche aufzusplitten. Objekt Objekt Objekt Objekt Wenn ich jetzt dieses Objekt habe, dann habe ich ein Problem es irgendwo zu speichern, obwohl noch insgesamt noch eine Menge Speicher vorhanden ist. Mehr als die Hälfte vom Speicher ist noch Frei, also sollte es doch möglich sein mein Objekt zu speichern. Compatction heißt nun: ich nehme alle Objekte und mache diese Compact. Was jetzt passiert bei der sweep phase, wir nehmen alle markierten objekte und bewegen diese nach links. Jetze habe ich speicherbereiche frei wo ich größere Datenblöcke speichern kann. Objekt Objekt

Mark & Compact Collector Zunächst wie der Mark&Sweep Alogrithmus Compacting GC bewegt die Objekte während der Sweep Phase Mark Phase Kompaktifiziert ROOT Wenn der GC den Speicher defragmentiert, dann nennen wir dies einen Compacting GC. So ein Compacting GC bewegt die Objekt während der sweep phase. Sweep pahse geht also über alle objekte und kopiert diese Jetzt kommt der Trick, welches Compaction möglich macht. References wie sie auf auf der SUN JVM ist. 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: 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. Alle Referenzen verweisen direkt auf das Objekt, um aufwändige Dereferenzierungen zu vermeiden, und werden nach einer Verschiebung geeignet angepasst.

Speicherverwaltung HEAP … Method Area MyObject object1; Object1 = new MyObject(); … ptr to class data instance data STACK Object reference ptr into heap … Bump pointer Free list Two machine word The first header word is a reference to the object's class. The second, contains other information, such as the identity hash code, and garbage collection status information Die Method area -darstellung der implementirung einer klasse RCP (Runtime Constant Pool) Felder Methoden attribute The first header word contains information such as the identity hash code and garbage collector status information. The second is a reference to the object's class. Only arrays have a third header field, for the array size. Class Myobject Extends java/lang/object toString(); hashCode() Method Area Class Data MyObject Class Data

Referenzen In der SUN Java-VM (Java JDK1.2.2) ist eine Referenzen kein Pointer. Es ist ein „Handle“ Ein Handle ist ein Pointer zu einem anderen Pointer Zu erstmal das Problem Nehmen wir an, Ich habe ein Objebt und eine menge Refernezierungen. Von lokalen variabeln, roots, wie auch immer. Wie kann ich das Objekt hier nehmen und es hierhin verschieben. Muss ich zurück und all die vielen Pointer finden und forwarden? Die antwrt ist NEIN. Dies liegt an den Refernecen in der SUN JVM. So das war mark & Sweep GC. Objekt referenezen Java2sdk -as indirekt handles relocation objects easy, performance bootleneck Hotspot - as dirct pointers - must adjust all pointers Object header Java2sdk 3 word hotspot 2 word Handles HEAP STACK ptr

Referenzen Diese „second“ Pointer befinden sich in einer separaten Tabelle HEAP STACK Handle Pool object ptr Jetzt kommt die idee Wir haben hier sb ein Objekt und eine menge refernezen zu dem Objekt. Es gibt ein spezielle Tabelle mit pointer zu objekten. In dieser Tabelle gibt es zu undserem Objekt einen Pointer. Alle unsere Referencen zeigen nun nicht auf das Objekt, sondern auf diesen einen Pointer. Sie sind also nur Pointer zum Pointer Wenn wir nun unser objekt nun hierher verschieben, dann müssen wir nur diesen einen Pointer ändern zu der neuen adresse. Alle die refernezen zeigen immer noch auf diesen pointer. Hiermit können wir objekte verschieben. Unsere pointer bleiben anderselben stelle in der tabelle, daher müssen die referenzierungen nicht geändert werden. Pointer sind viel kleiner als unsere objekte und haben diselbe größe, deshalb müssen wir uns hier nicht um fragmentierung gedanken machen. Es wird nie passieren dass ein pointer kein platz zwischen anderen pointer findet. Es sei den die tabelle ist komplett belegt. Diese seceond Pointer befinden sich in einem seperaten Table. Und diese ist groß genung, sodsass wir uns normalerweise keine gedanken machen müssen, dass nicht genug pointer erstellt werden können. object

Copying Garbage Collector Speicher ist in 2 Bereiche aufgeteilt: Old Space New Space Finde lebende Objekte mittels DFS Wenn es lebende Objekte im Old Space findet, wird es unverzüglich ins New Space bewegt Die Objekte werden im New Space in den bestmöglichen Speicherplatz bewegt Beim nächsten GC werden Old und New-Space vertauscht Eine andere, aber ähliche ist Copying GC. Vorteil. Es ist schneller, da es nur eine Phase hat. Es besucht die Objekte nur 1mal. In Mark & Sweep werden die Objekte 2mal durchlaufen. Unser Speicher ist in 2 geteilt. Old Space, da sind gegenwärtig unsere Objekte. New Space, dorthin werden unsere Objekte gebracht. Starte Der Copying GC macht folgendes. Die objekte werden im new space in den werstmöglciehn Speicherplatz bewegt. So Compaction ist bereits im Alogritmus mit eingebaut. Wenn wir alle live Objekte ins new space bewegt haben, dann müssen wir uns nicht mehr um unser garbage kümmern. Die können wir einfach gesagt vergessen. Wir müssen die nicht mehr freigeben. Der alte space wird einfach gelöscht. D.H nicht wir beschreiben den old space mit nullen, sondern einfach vergessen, dass da eine datenstruktur drin liegt. Wenn der old space benötigtwird, dann legen wir eine neue Datenstruktur an. Beim nächsten mal, wenn wieder eine GC nötig ist. Dann werden old Space und new space einfach getauscht. Vorteil: schnell Nachteil: Es steht leider nur halber speicher zur verfügung. ROOT ROOT Old Space New Space

Copying Garbage Collector Schneller als M&S, da nur eine Phase Vorteil: Geschwindigkeit Nachteil: Halbierung des Speichers

Generational Garbage Collector Die meisten Objekte haben einen kurzen Lebenszyklus Aber einige Objekte leben länger Gernerational Collectors haben 2 oder mehr Generations Können eine unterschiedliche Größe haben Größe kann variiert werden Mark Sweep Copying Jetzt möchte ich euch andere GC vorstellen wo beide implementationen enhalten sind. Generational Garbage Collector. Gernerational entstand dadurch, dass entwickler beim untersuchen vieler Speicher allocationen in vielen großen Applikationen, festgestellt haben, dass Viele Objekte nur einen kurzen Lebenszyklus besitzen. Also in Vielen Programmen werden Objekte erstellt und sind nur kurz in verwendung und sterben danach. Aber es gibt wenige die doch eine längere Zeit leben. Eine Regel in der Gernational GC ist, welches sehr gegensätzlich zum mehnsclichen Leben ist, umso länger die Objekte leben, umsolänger leben werden sie weiterhin leben. Wenn ein Objekt eine bestimmte Zeit überlebt hat, dann wird angenommen, dass das Programm das Objekt für eine sehr lange Zeit weiterhin benutzt wird. Das ist die Grundlegende Idee des Gernerational GC Größe kann während der laufzeit ändern.

Generational Garbage Collector Old generation Mark & Sweep GC (infrequently) Young generation Copying GC (frequently) tenured Survivor Spaces Survivor Spaces Eden full So wie sieht es bei SUN´s JVM aus. Es gibt einen großen untershcied zwischen Old Gernation Young Generation. Annahme Old Objects, leben schon lange und werden sich auch weiterhin nicht grundlegend ändern. Daher wollen wir diese auch im Speicher möglichst Compct halten. Da sie nicht so oft sterben können wir dies einfach mit einem Mark & Sweep Collector realisieren. Dieser ist zwar langsam, aber wir müssen diesen Collector nicht so oft bentuzen. Daher benutzt man hier lieber einen, der einem den Meisten Speicher zur verfügung stellt , als den schnellsten. Bei den young generations ist dies aber genau anders rum. Hier benötigt man einen schnellen GC, da hier Objekt einen sehr kurzen lebenszyklus haben.Fragmentierung ist nicht so wichtig, da viele von ihnen schnell sterben. Tenured = unkündbar Middel age genartion Ganz unten haben wir viel Platz, SUN nennt ihn EDEN, Eden ist ein Ort wo viele Objekte erzeugt werden und hier auch kurze Zeit später sterben. Um Eden schnell zu halten, macht man sich keine gedanken über die fragmentierung. Wenn Objekte erzeugt werden, dann werden diese hier einfach allokiert, fast allocation, which allows allocations into the Eden to be very efficient by using the bump-the-pointer technique Eden wartet einfach bis Eden voll ist. Wenn Eden voll ist, dann kommt alles was Eden überlebt hat, eine Stufe höher. Genannt der Survior Space. Danach wird alles gelöscht was in Eden war. So bleibt Eden super schnell. Die beiden survivor spaces, sind nichts anderes, als die 2 speicherhälfen eines copying Garbage Collector. Der Survivor space ist expandable. Wenn objekte lange genug , bzw. eine bestimmte anzahl von Copying Collection überlebt haben, kann man durch einen zähler realisieren, dann nennt man diese tenure. Diese werden zu der old generation gebracht. Die sitzen dann da und warten. Copying läuft frenquntly. Keep tracks of all references from old to young generation…. Wie? Durch ein seperaten table. Klingt expensive, aber alte objete zeigen nicht so oft auf junge objekte. Daher beeinträchtigt es die effizients nicht so dramatisch in einem üblichen programm. Add them to roots of copyg collector. Wenn ein young object collected wird, dann muss nur aus der tabelle die alten rückverfolgt werden.. Allerdings muß bei der Ermittlung der Erreichbarkeit nicht nur der Bereich der jungen Objekte, sondern auch die Referenzen aus dem Mature-Space in die jüngere Generation berücksichtigt werden müssen. Um zu diesem Zweck nicht den gesamten Mature-Space nach solchen Referenzen durchsuchen zu müssen, merkt sich die Speicherverwaltung diese Referenzen in einer separaten Liste. Dazu wird die bereits erläuterte Schreibsperre verwendet: Jeder Versuch, eine Referenz in ein Objekt der älteren Generation einzutragen, wird abgefangen. Wenn die Referenz in eine jüngere Generation zeigt, wird die entsprechende Liste aktualisiert. Wurzeln sind alle Objekte im Stack, globale Variablen sowie alle Objekte, die in "älteren" Generationen (als diejenigen im FROMSPACE) liegen, und "junge" Objekte referenzieren. Beobachtung zeigt, dass alte Objekte selten auf junge zeigen, da dies nur durch "späte Zuweisung" möglich ist. Um herauszufinden, welche Objekte aus "älteren" Generationen referenziert werden, gibt es verschiedene Methoden: Remembered Set: Jedes Update eines alten Objekts trägt die geschriebene Adresse in ein Remembered Set ein. Card Marking: Teile die Gi in Blöcke der Größe 2k ein. Beim Update markiere in einem Bitvektor den betroffenen Block, bei GC betrachte alle Altobjekte des markierten Blocks als Wurzeln. Page Marking: Verwende die Blöcke des virtuellen Speichers; markiere Blöcke aus alten Generationen als schreibgeschützt. Wird ein altes Objekt verändert, gibt es einen memory fault: fange diesen ab und markiere Block im Bitvektor. W e a k g e n e r a t i o n a l h y p o t h e s i s : ─ M o s t o b j e c t s a r e s h o r t - l i v e d ─ F e w r e f e r e n c e s f r o m o l d t o y o u n g o b j e c t s EDEN All Objects born here Most die here

Aktionszeiten des Garbage Collectors Garbage Collector läuft, wenn zu wenig Speicher zur Verfügung steht (low Memory) System zur Zeit ungenutzt (idle) Zu einer beliebigen Zeit Explizit vom Programm aufgerufen System.gc(); Keine Garantie für das Beenden eines Objektes Daher sollte man beim Entwurf sich nicht darauf verlassen!!! Bei jedem Rechenschritt (buchstäblich bei jeder Rechenoperation, ob + , - , * oder /) wird für das Ergebnis (oder Zwischenergebnis) ein neues Objekt erzeugt. Eine kleine Überschlagsrechnung für eine Hypothek (30 Jahre, monatliche Bedienung, tagesgenaue Zinsberechnung, vierteljährliche Tilgungsgutschrift, Kontokosten etc.) endet da ganz schnell mit einer Million von kurzlebigen Objekten. Jedes dieser Objekte wird nur erzeugt, um einen Zwischenwert darin zu speichern. Nach dem nächsten Rechenschritt ist es überflüssig. Es gehört dem GC – und der schuftet sich zu Tode. Don’t allocate as much memory – Less work for your application – Less work for the garbage collector – Should improve performance • (Why only “should”?) • Don’t hold on to references – Null out pointers in data structures – Or use weak references

Auswahl eines Garbage Collectors Auswahl anhand folgender Ziele: Pause Zeiten Durchsatz Header-Größe Serial Collector Default Collector XX:+UseSerialGC Parallel Collector Multiprozessor optimiert XX:+UseParallelGC Conccurent Collector Echzeitanwendungen XX:+UseParallelOldGC Design Choices A number of choices must be made when designing or selecting a garbage collection algorithm:

Anforderungen an eine Garbage Collection (SUN) safe and comprehensive Mark & Sweep / Copying GC efficiently without introducing long pauses Generational GC -> Serial/ Parallel/ Concurrent GC limitation of fragmentation Copying GC / Bump Pointer scalability Verteilung auf mehrere Threats (Parallel/ Concurrent GC) Sicher und vollständig d.h. lebende objekte dürfen nicht fälsherweise entfernt werden und Garbage darf nicht übrig gelassen werden. Fast fast allocation fast, promt reclaimation, minimal distruption of running program Allocation should not become a scalability bottleneck for multithreaded applications on multiprocessor systems, and collection should also not be such a bottleneck.

Tuning des SUN JVM Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html Per Kommando-Zeilen Befehle: Informationen über HEAP und GC verbose:gc Verhältnis zwischen Young Generation und Old Generation XX:NewRatio=3 Verhältnis zwischen Survivor Spaces und Eden XX:SurvivorRatio=6 Heap Größe festlegen java -Xms32m -Xmx128m MyClassName By default, the young generation size is controlled by NewRatio. For example, setting -XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one fourth of the total heap size. If survivor spaces are too small, copying collection overflows directly into the tenured generation. If survivor spaces are too large, they will be uselessly empty

Literatur & Quellen Richard Jones & Rafael Lins Garbage Collection: Algorithms for Automatic Dynamic Memory Management John Wiley & Sons, New York, 1996 Garbage Collection in the Java HotSpot Virtual Machine http://www.devx.com/Java/Article/21977 Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html Java™ Virtual Machines http://java.sun.com/j2se/1.5.0/docs/guide/vm/index.html Java's garbage-collected heap http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html Chapter 5 of Inside the Java Virtual Machine http://www.artima.com/insidejvm/ed2/jvm.html

Rückblick Gut, dass es eine Garbage Collection gibt, oder ? Speicherdarstellung in einer Java VM Heap, Stack, Method Area Speicher Allokation / Deallokation „NEW“ Konstruktur, Referenzen Automatische Speicherbereinigung Garbage Collection 2 Verfahren kennen gelernt Mark & Sweep Collector Copying Collector 3 verschiedene Garbage Collectoren in SUN´s JVM Serial, Parallel & Concurrent Collector Gut, dass es eine Garbage Collection gibt, oder ? Akzeptables miitel zwischen vor und nachteilen