[fpc-devel] Boehm garbage collector for freepascal

[Michael Van Canneyt]

On Mon, 15 Nov 2010, Marco van de Voort wrote:

> In our previous episode, Thaddy said:
>>
>> You can find boehm garbage collector bindings for freepascal, incl.
>> replacement memory manager at
>> http://freepascal.thaddy.co.uk/fpc_boehm_gc.zip
>> For win32 a prebuild dll is included
>> For other platforms you need to build the gc library from source (included)
>> Please test, I am especially curious how it behaves on other platforms.
>> freepascal.thaddy.co.uk/fpc_boehm_gc.zip
>>
>> I Also have a question:
>> (After you played with the example and read the docs)
>
> Oh. Am I supposed to do that? :-)
>
> (I just collect info about this subject because it is a recurring white
> elephant. Regularly there is talk about it, but nobody has seen a working
> implementation, and nobody knows if proof of implementation on  C++
> really does translate to Delphi. (like the finalization bit below)
>
> I myself are not interested in GC in my current job (but was
> in my previous webapp job)
>
>> Suppose I want a GC version of freepascal, would it be enough to patch
>> TObject.InitInstance/TObject.FreeInstance for finalization and adapt
>> heap.inc and do a make clean/make all?
>
> I was thinking that one would install a heapmanager with a freemem that does
> nothing.  Unfortunately the prototype can't zero the pointer (like
> freeandnil does)
>
> All allocations are eventually getmem/freemem, so redirecting getmem to the
> gc's prefered memory allocation and making freemem a no-op would be enough I
> guess.
>
>> Tobject descendants may require finalization before the garbage
>> collector cleans them, hence my question.
>
> Hmm, yes. That means indeed the GC must be able to call a callback on a
> block that must be freed, and some call to finalize must be made there. But
> will you have enough context to do so?
>
> Or will we simply not finalize and let the GC collect ansistrings and the
> like too? I always assumed that.

You must finalize, because ref. counting of interfaces etc. need to be taken
care of. Interfaces may live outside the FPC memory space, and are therefor
not accessible to the GC. If you want to let the GC collector handle all
that, you're in essence copying what the the destructor does, and that
seems like a wrong approach.

Michael.