[fpc-devel] Boehm garbage collector for freepascal
DrDiettrich1 at aol.com
Tue Nov 16 04:12:47 CET 2010
> 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.
More information about the fpc-devel