Mon, 09 Aug 2010 19:03:16 GMT
The Old New Thing hat grad einen interessanten Artikel zu Garbage Collectors. Obgleich ich mich schon öfters damit beschäftigt habe, ist mir diese eigentlich offensichtliche Ansicht grade neu gewesen.
Ein Garbage Collector ist demnach ein Mechanismus der unendlichen Speicher simuliert.
Er begründet weiterhin was die formalen Folgen daraus sind, dass zum Beispiel wenn ein Programm immer genügend Speicher allokieren kann, der "Null-Garbage-Collector" der nichts tut ein ausreichender GC ist. Daraus leitet er korrekt ab, dass man nicht davon ausgehen kann, dass finalizer vor dem Beenden eines Programmes aufgerufen werden.
Ich kann in diesem Punkt nicht ganz zustimmen. In einem Kommentar heißt es dann noch, es gibt von Garbage Collectoren echt verschiedene Strategien dies zu tun, und ich denke auch, unter Garbage Collectors versteht man einen ganz bestimmten Ansatz die Simulation unendlichen Speichers zu erzielen, nämlich während der Laufzeit nach Objekten zu suchen die nicht mehr vom Hauptprogramm referenziert werden.
Schwache Referenzen und Finalizer sind zum Beispiel Techniken, die außerhalb eines solchen Ansatzes nicht notwendigerweise Sinn ergäben. Und man kann im Prinzip argumentieren, ein GC sollte garantieren dass Finalizer aufgerufen werden, in einer perfekten Welt wäre das schön, aber leider geht das nicht immer so einfach, heißt, seine Conclusio, sich darum zu kümmern und den GC nur als Auffangnetz anzusehen, finde ich durchaus sinnvoll.
Generell finde ich aber vor Allem den Denkansatz schön, mal nicht anzufangen über einen Haufen Garbage Collectoren zu reden, sondern sich erstmal zu überlegen, was das Ganze formal eigentlich ist, und daraus Konsequenzen abzuleiten. Eine Denkweise, die in der modernen pragmatisierten Informationstechnik immer seltener anzutreffen ist.
Ein Garbage Collector ist demnach ein Mechanismus der unendlichen Speicher simuliert.
Er begründet weiterhin was die formalen Folgen daraus sind, dass zum Beispiel wenn ein Programm immer genügend Speicher allokieren kann, der "Null-Garbage-Collector" der nichts tut ein ausreichender GC ist. Daraus leitet er korrekt ab, dass man nicht davon ausgehen kann, dass finalizer vor dem Beenden eines Programmes aufgerufen werden.
Ich kann in diesem Punkt nicht ganz zustimmen. In einem Kommentar heißt es dann noch, es gibt von Garbage Collectoren echt verschiedene Strategien dies zu tun, und ich denke auch, unter Garbage Collectors versteht man einen ganz bestimmten Ansatz die Simulation unendlichen Speichers zu erzielen, nämlich während der Laufzeit nach Objekten zu suchen die nicht mehr vom Hauptprogramm referenziert werden.
Schwache Referenzen und Finalizer sind zum Beispiel Techniken, die außerhalb eines solchen Ansatzes nicht notwendigerweise Sinn ergäben. Und man kann im Prinzip argumentieren, ein GC sollte garantieren dass Finalizer aufgerufen werden, in einer perfekten Welt wäre das schön, aber leider geht das nicht immer so einfach, heißt, seine Conclusio, sich darum zu kümmern und den GC nur als Auffangnetz anzusehen, finde ich durchaus sinnvoll.
Generell finde ich aber vor Allem den Denkansatz schön, mal nicht anzufangen über einen Haufen Garbage Collectoren zu reden, sondern sich erstmal zu überlegen, was das Ganze formal eigentlich ist, und daraus Konsequenzen abzuleiten. Eine Denkweise, die in der modernen pragmatisierten Informationstechnik immer seltener anzutreffen ist.
Show comments (Requires JavaScript, loads external content and cookies from Disqus.com)