Question from a non-user: Garbage Collection
in [Lisp]
|
Prev: TPS
Next: Style, or lack thereof in Graham's ANSI CL
From: Kaz Kylheku on 21 Dec 2009 17:58 On 2009-12-21, Vend <vend82(a)virgilio.it> wrote: >> If you ask me, no. Reference counting is not garbage collection. >> >> I may have thought so once, but I changed my mind, and I'm still getting >> smarter. Therefore, it's smarter to regard refcounting as something >> other than, or less than garbage collection. Q.E.D. :) >> >> To me, garbage collection means: computing the lifetimes of objects without any >> help from extra memory-management-related instructions added to the compiled >> program. > > In generational garbage collectors, the program will execute > additional instructions each time a reference to a young object is > stored inside an old object. Indeeed, because such stores violate the desireable property that pointers only point from newer generations to the older, and never the other way around. If the memory manager is not informed about this situation, it will wrongly reclaim the young objects, if they are not referenced by objects that are as young young, or younger, leaving the old-to-young references dangling. Any memory manager that needs to be informed this way, is not GC. If you can find a way to solve this problem without help from the program, then you have GC. > Do you consider generational GC a proper form of GC? No, I don't. This so-called ``garbage collector'' cannot collect garbage properly from some machine-language programs which pose no problems to the the full garbage collector. Garbage collection is anything that has exactly the same semantics as an abstract model described in terms of mark and sweep, and can be used as a binary drop-in replacement for a reference implementation thereof without recompiling any new machine code.
From: George Neuner on 22 Dec 2009 11:33
On Mon, 21 Dec 2009 22:58:53 +0000 (UTC), Kaz Kylheku <kkylheku(a)gmail.com> wrote: >On 2009-12-21, Vend <vend82(a)virgilio.it> wrote: >>> If you ask me, no. Reference counting is not garbage collection. >>> >>> I may have thought so once, but I changed my mind, and I'm still getting >>> smarter. Therefore, it's smarter to regard refcounting as something >>> other than, or less than garbage collection. Q.E.D. :) >>> >>> To me, garbage collection means: computing the lifetimes of objects without any >>> help from extra memory-management-related instructions added to the compiled >>> program. >> >> In generational garbage collectors, the program will execute >> additional instructions each time a reference to a young object is >> stored inside an old object. > >Indeeed, because such stores violate the desireable property that pointers only >point from newer generations to the older, and never the other way around. > >If the memory manager is not informed about this situation, it will wrongly >reclaim the young objects, if they are not referenced by objects that are >as young young, or younger, leaving the old-to-young references dangling. > >Any memory manager that needs to be informed this way, is not GC. > >If you can find a way to solve this problem without help from the program, >then you have GC. > >> Do you consider generational GC a proper form of GC? > >No, I don't. > >This so-called ``garbage collector'' cannot collect garbage properly >from some machine-language programs which pose no problems to the the full >garbage collector. > >Garbage collection is anything that has exactly the same semantics as an >abstract model described in terms of mark and sweep, and can be used as a >binary drop-in replacement for a reference implementation thereof without >recompiling any new machine code. Jones and Lins book is pretty much the bible of GC. Don't be overly concerned by the old publication date: little has changed since it was written. Definitely worth a read if you're interested in GC. Jones and Lins, "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", ISBN 0-471-94148-4. George |