Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 9:48 PM +0200 8/20/04, Leopold Toetsch wrote: >>0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD" >>subsystem is the stop-the-world mark & sweep collector that recycles >>object headers. The "GC" is the copying collector for variable sized >>string and other buffer memory. >>The incremental mark & sweep collector (src/gc_ims.c) is an alternative >>for the DOD thingy and reuses some code in src/dod.c.
> Nah, this is actually correct. The DOD does, in fact, look for dead > objects (if you consider PMC and buffer headers objects. ... and frees dead objects. That's exactly a mark and sweep garbage collector. DOD is the first phase of that garbage collection. It would be rather useless, if we only detect garbage and not collect it. It's misleading. > ... The GC, on > the other hand, collects up garbage memory, making the assumption > that all the objects marked live are, in fact, live. Separate phases, > separate purposes. The "GC" is a separate phase, yes. It's a second garbage collector, this time a copying collector that takes advantage of liveness information of fix-sized headers. And it does *not* run on any assumption of all being marked live. It runs on the fact that all that's marked dead is dead. If a "DOD" run preceded the "GC", then it collects all dead buffer memory. If not it would run inefficiently and copies buffer memory around that could be dead. > This works on the presumption that our mutable strings chew up memory > more than objects in the normal running of things, which seems bourne > out by the programs that look like 'normal' code. Well, while it's an independent GC phase with a special purpose it can run efficiently only after DOD. leo
