[fpc-devel] Boehm garbage collector for freepascal

Hans-Peter Diettrich DrDiettrich1 at aol.com
Tue Nov 16 04:12:47 CET 2010


Thaddy schrieb:

> Actually, I am *calling* the destructor in the finalizer, not copying 
> it. AFAIK this should take care of it.

IMO destructors and finalizers are mutually exclusive, I remember a note 
like "Why a garbage collector never should call an destructor", that at 
least applies to mark-sweep GC.

It should be clear that a destructor, that destroys further (owned) 
objects, will confuse an mark-sweep garbage collector, since it can 
invalidate the marks. Consequently all allocated memory areas/objects 
should be flagged as either managed or unmanaged. Then FreeMem can 
decide, inside the memory manager, whether the memory block should be 
released immediately (if unmanaged), or should be marked for later 
deletion (if managed). Dunno about the concrete Boehm implementation...

> Regarding refcounted strings: the way it is implemented here doesn't 
> carry any prize for beauty, but it seems to work alright.

That's a different GC model, not mark-sweep. Eventually the un/managed 
flag has to be extended, into managed-by-refcount and managed-by-mark-sweep.

> As Marco stated, and is provided, there is a need for a callback and 
> that is exactly what Boehm has provided for.

That callback may be intended to perform further *finalization*, not 
*destruction*, of related objects. The FPC/Delphi Finalize procedures 
and destructors should not be confused with finalizers in the GC sense. 
A GC finalizer only should clear (Nil) references to other objects, and 
possibly mark the object as finalized, what might be done after the 
callback returns. Then the collector phase of the GC will know which 
objects really can be removed from memory, and will not have to be taken 
into account in the next mark phase.

DoDi




More information about the fpc-devel mailing list