Infoportal
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| software:deep:dev:rts:heap [2013-12-29 16:57] – Externe Bearbeitung 127.0.0.1 | software:deep:dev:rts:heap [Unbekanntes Datum] (aktuell) – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1 | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== Heap Manager and Garbage Collection ====== | ||
| - | ===== General Information ===== | ||
| - | Currently we support a simple mark & sweep algorithm. With this the mark phase must not be interrupted, | ||
| - | | ||
| - | ===== Initialization ===== | ||
| - | At startup the roots of all loaded classes are collected. Roots are static references to objects. An Integer array with this size is allocated and filled with the addresses of the roots. This array and also the array with the free lists are roots themselves. The array with the free lists will be marked in the mark phase which precludes sweeping but its entries will not be followed because it is an Integer array. Following would be wrong anyway.\\ | ||
| - | At the beginning the whole free heap will be entered as a single free block. | ||
| - | ===== Free Blocks, Allocation ===== | ||
| - | There are 8 lists with block sizes of (Bytes) 16, 32, 48, 64, 80, 96, 112 and >= 128. At the very beginning there is no array with theses lists. Therefore the allocation must be done "by hand". Only after the class constructor of the class //Heap// is executed the rest of the heap can be entered as a free block. \\ | ||
| - | To be able to follow the free blocks (when searching a new block or when sweeping) the structure below is used: | ||
| - | [{{ .: | ||
| - | Das Feld //size// gibt an, wie gross der Block ist, in //next// steht die Adresse des nächsten freien Blocks. Es wurde darauf verzichtet eine Java-Klasse für diese freien Blöcke zu schaffen. Der Grund liegt darin, dass diese freien Blöcke in benutzte und umgekehrt umgewandelt werden müssen. Auch ist die direkte Programmierung effizienter. | ||
| - | [{{ .: | ||
| - | Bei der Allokation wird geprüft, wie viel freier Platz auf dem Heap noch vorhanden ist. Wenn dieser freie Platz eine bestimmte Untergrenze unterschreitet, | ||
| - | |||
| - | ===== Mark-Phase ===== | ||
| - | Ausgehend von den Wurzeln werden alle benutzten Blöcke markiert. In allen Objekten muss auch den darin enthaltenen Referenzfeldern gefolgt werden. Dazu stehen im Typdescriptor die Offsets aller Referenzfelder. | ||
| - | |||
| - | ===== Sweep-Phase ===== | ||
| - | In der Sweep-Phase muss der gesamte Heap durchlaufen werden. Dabei wird von Block zu Block vorangegangen. Jeder Block (ob frei, markiert oder nicht mehr benutzt) muss also auch die Information über seine Blockgrösse beinhalten. Dies ist bei freien Blöcken und bei normalen Objekten direkt im Blockanfang enthalten. Bei Arrays muss diese Information mit Hilfe des Typdescriptors gefunden werden. | ||
| - | [{{ .: | ||
| - | |||
| - | Grundsätzlich könnte die Sweep-Phase unterbrechbar gemacht werden (mit einem Task oder indem einfach ein Stück durchlaufen wird), im Moment ist das aber nicht so gelöst. \\ | ||
| - | **Achtung** | ||
| - | Wird ein bestimmter Block frei (d.h. die letzte Referenz darauf geht verloren), dann wird dieser Block unter Umständen erst nach zweimaligem Mark/Sweep als freier Block markiert. Begründung: | ||
| - | |||
| - | ===== Strings ===== | ||
| - | Strings werden wie normale Objekte behandelt. In der Mark-Phase werden auch konstante Strings markiert, obwohl sich diese im Konstantenblock einer Klasse befinden. Das könnte zu einem Problem führen, wenn sich dieser Block in einem Flash befindet und dieses keinen Schreibzugriff erlaubt. Das ist aber normalerweise nicht so. Natürlich werden konstante Strings beim Sweepen nicht eingesammelt, | ||
| - | |||