Re: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)

[Jim Blandy <jimb at savonarola dot red-bean dot com>]

> >> You aren't describing the Boehm GC here.  It also has generational
> >> capability.  Boehm is working on making it concurrent as well.
> 
> Jim> What kind of write barrier does it have?
> 
> It uses the VM.

Okay --- this illustrates my only objection to the Boehm GC.

Boehm is really sharp.  His papers are excellent; the posts I've read
from him are a step above.  I'm sure he does a lot of stuff better
than we would on our own --- we should be watching his ideas closely.

But his GC is trying to solve a harder problem than ours: he's trying
to replace malloc in GC-ignorant programs.  In Guile, we can demand a
lot more from our code:
- We can require that they use a software write barrier.  Software write
  barriers are much more efficient than Unix VM barriers, according to
  all the papers I've read.  But for Boehm, it's not an option.
- We can require that all their objects start with cells, from which we
  can extract typing information quickly and reliably.
- We can focus our energies on allocating cells of a few small sizes,
  instead of arbitrary-sized blocks.

Now, those are the theoretical arguments, and must be taken with a
grain of salt.  The clincher would be benchmark results, in either
direction.  If Boehm is competitive with the (still non-existent,
right?) Guile generational GC, then I would suggest that we get out of
the GC business, and delegate the maintenance of our GC to Boehm.