Re: garbage collection experiment

[Michael Livshin <mlivshin bigfoot com>]

Havoc Pennington <hp redhat com> writes:

>    Boehm has hooks to register a finalizer for a block, but these
>    can't really be used for GObject; one issue is that it can't
>    collect cycles involving finalized objects, because normally if A
>    points to B, it finalizes A then B, but if A and B are in a cycle,
>    there's no safe finalization order. Another issue is that
>    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.

regarding finalizers (I had a lot to do with them relatively
recently, so...):

* the problem with cycles in finalized objects is basically semantic.
  it's also, in my experience, not very frequent, and easy to detect,
  warn about, and fix (by breaking the relevant cycles).  you could
  also ignore it altogether by not checking for interdependencies in
  the finalized objects, but that has even worse problems.

* the best way to run finalizers is "manually" (synchronously, that
  is), probably in the beginning of each event loop or some such.  I
  *think* Boehm has a way to arrange something like that, but I'm not
  sure.  come to think about it, the beginning of the event loop is
  probably the best place to run the GC in general.

regarding the overhead:

* it's frequently exegerrated.  it *may* be a problem for you, as you
  apparently want to play with refcounts in the finalizers.  well:
  don't.  you have a GC, you can just ignore the refcounts, no?

>  - There are certainly portability issues with the Boehm collector, in
>    particular right now it just punts on shared libraries and only
>    builds a static lib, and I'm using an unportable hack to get it
>    into a shared lib. The gcj team has it autotoolized and Tom says
>    Boehm may merge that upstream sometime. Of course the collector
>    implementation itself is a huge nest of platform dependent hacks,
>    unavoidably, but it's ported to most platforms.

regarding portability:

* pretty much all of Boehm's portability problems stem from doing the
  magic things like looking at the page dirty bits and scanning the
  static data section (aggravated by shared libraries).  if you can
  live with having to register your static pointers by hand (Guile
  users don't seem to mind at all, but who knows), you should be able
  to derive a highly portable version of the collector.  or use a
  different collector, like the one from Guile, or STk, or maybe yet
  another one -- they are pretty easy to write.  Guile's collector has
  a nice (IMHO, as I wrote it) finalization facility in the CVS
  version.

* point being, Boehm's collector tries to be a drop-in magic
  replacement for malloc.  most (nay, all) of its protability problems
  are because of the "magic" part.  I don't think you *need* the magic
  -- you are not looking for a magic malloc.

-- 
I knew you weren't really interested.