[*]... so langsam, dass ich schneller neue Sachen ausm Regal hole, als er wegräumen kann
Weder für Java noch für C# schreibt die Spezifikation vor, dass der Garbage Collector langsam sein muss
Seit Java 5 ist die parallele Garbage Collection per Default eingeschaltet, wenn es sich um eine Maschine mit mehreren Prozessoren oder -kernen handelt. (Siehe Angelika Langer, Generational Garbage Collection,
http://www.angelikalanger.com/Articl...oungGenGC.html) - dann können neben den Anwendungsthreads mehrere GC Threads laufen, die sich die einzelnen GC Strategien und Speichertypen untereinander effizient aufteilen können.
Dass man in Delphi alles selber machen darf ist schön, schön ist aber auch wenn einem die Arbeit abgenommen werden kann - weniger Codierungsaufwand für das Schreiben von Destruktoren, weniger Kopfzerbrechen über den 'richtigen' Zeitpunkt ab dem ein Objekt freigegeben werden kann, mehr Zeit für andere Pfadfindertugenden
Beispiel, was so ein Garbage Collector bringt: wenn eine Reihe von Objekten zyklisch referenziert sind (A -> B -> C -> A), und nur auf eines der Objekte in diesem Ring noch über eine Variable zugegriffen werden kann, darf man natürlich die anderen noch nicht freigeben. Sobald aber diese eine Variable nicht mehr aus dem Programm erreichbar ist (bei Verlassen einer Prozedur in der diese Referenz existierte, oder wenn sie auf nil gesetzt wird), dann sind die daran hängenden Objekte A bis C nicht mehr erreichbar. In Java werden solche Dateninseln erkannt und freigegeben. In Delphi hat man viel Spass mit der Programmierung eines entsprechenden Aufräumalgorithmus...