This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)
> >> 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.