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

[Miroslav Silovic]

Tom Lord <address@hidden> writes:

> Would you have noticed if your application leaked memory?

Yes. I specifically traced bytes-allocated (since it did leak memory
at one point, due to erroneous handling of scm_must_malloc on my
part).

> Would you have noticed if it leaked other kinds of resources?

It didn't use other kinds of resources.

> Would those bugs make a big difference to the usefuleness of your
> specific application?

Anything that runs for hours with insane garbage generation would put
a huge spot on radar if it leaked.

> 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.

To counter your cross-examination, are you sure that these bugs are
conservativism-related? Also, were they unbounded leaks or just a few
elements left over in the table (which would NOT be a GC bug, since GC
is not *supposed* to guarantee prompt cleanups)?

> 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.

I would not like to have to spend the ammount of man-hours that went
into Emacs for my own applications.

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

Agreed... provided we can reach an agreement about what these
limitations are :)

-- 
How to eff the ineffable?