Re: garbage collection experiment

[Andreas Bogk <andreas andreas org>]

Havoc Pennington <hp redhat com> writes:

> Observations after further testing and discussion with Owen:

Thanks, these have been very helpful.

>    Anyhow, doing more than free/unref in a finalizer is conceptually 
>    broken even now, but broken in practice with a collector most 
>    likely, since finalizers will just get skipped.

Wouldn't that mean that we would be better off completely without
ref/unref when using garbage collection?

>    finalizers slow stuff down and add overhead. Finally most objects
>    won't expect to be inside g_malloc() when finalized, which is where
>    the collector will do the finalization.

One could set GC_finalize_on_demand to 1, and call
GC_invoke_finalizers() from an idle function.

>    It might be possible to have a Boehm-registered finalizer that
>    simply adds an object to a list of objects, then you call
>    GObject-level finalizers in some kind of idle handler, which keeps
>    finalizers from being called from inside a g_malloc() and avoids
>    some reentrancy problems; but, there are other issues that arise
>    with that.

Would these issues remain when GC_invoke_finalizers() is used?

>  - I can't get the incremental GC feature of the Boehm collector to 
>    make any difference; it always does full collections anyway for 
>    some reason. I guess it's good the full collector is fast enough,

The garbage collector is fast enough for practical purposes, that's
true. But I've seen the incremental collector work, and it prevents
any stopping at all. The downside is that incremental collection is a
little slower, but that's probably due to the emulation of dirty bits
using mprotect() under Linux.

>  - There are certainly portability issues with the Boehm collector, in
>    particular right now it just punts on shared libraries and only

It works for me as a shared libraries, but this varies between
platforms.

Andreas