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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
