Re: gc and call/cc design space notes (DRAFT)

[Tom Lord]

       One datapoint: SART (my 3d renderer) didn't have any problems
       whatsoever with conservativity, despite running for hours at
       100% CPU usage with LOTS of cells and smobs pointing at each
       other, and lots of garbage allocation (but it did have problems
       with noncompacting malloc, and debugging scm_must_malloc
       sucked).

       I'd kinda go with Hans Boehm conclusions about this.

Would you have noticed if your application leaked memory?  Would you
have noticed if it leaked other kinds of resources?  Would those bugs
make a big difference to the usefuleness of your specific application?
The appearence and seriousness of conservative GC bugs are intensely
application specific.  Boehm's arguments apply to some kinds of
applications, but not to others.

Here is another anecdote: a 10 or so line test program designed to
test weak hash tables in Systas Scheme (which is essentially the same
as Guile wrt. GC) has detected conservative GC bugs with noticeable
frequency in runs lasting less than 60 seconds.  Such bugs are
sensative to stupid things like compiler options and changes to
completely unrelated code -- they don't show up on every run of the
test program; they are difficult to reliably reproduce.

The version of Emacs I use is pretty much rock solid, run even for
days at a time, even as I add to the list of .el files I load.  I have
no hard data, but I presume a similar result is obtained by 10s of
thousands or more users.  I rely upon this stability for my daily
work.  I know others do as well.

Conservative GC bugs could easily cause Emacs to sometimes flake out
and consume large or even core-dump-causing amounts of memory.  They
could very well cause other kinds of bug, as well. I would not want to
see conservative GC appear in Emacs, or any similar application.

The warnings in the Guile data sheet should mention the limitations of
conservative GC.

-t