This is the mail archive of the
mailing list for the Guile project.
Re: on the topic of GC.
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: on the topic of GC.
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 09 Feb 2000 16:30:33 +0200
- Cc: Jim Blandy <jimb at red-bean dot com>, guile at sourceware dot cygnus dot com
- Organization: who? me?
- References: <Pine.LNX.email@example.com>
[ warning: following are some points based on real-life experience
with conservative GC (Boehm's). they may be relevant or not. ]
Dirk Herrmann <firstname.lastname@example.org> writes:
> Nobody seems to have exact numbers about the frequency of
> false positives.
indeed. I am personally very interested to know of any garbage
retention problems in long-running SCM/Guile programs on the SPARC.
the stack handling on the SPARC is such that Boehm goes to
considerable kludges to clean the stack whenever possible and safe.
SCM/Guile's GC doesn't. so... any horror stories?
> * scanning the stack takes time.
peanuts, in my experience. real peanuts. but do keep in mind that
the Boehm GC is *very* efficient at determining whether a pointer is
interesting or not, and SCM/Guile's GC is much less so (which is
certainly fixable, and thus doesn't really change my point).
> * conservative gc depends on the compiler to store pointers on the stack
> in an unmodified way. This might not be an issue with existing compilers,
> but still is an uncleanlyness that I personally don't like.
I would say that at least existence of an option to the compiler to
not mangle pointers will always be guaranteed - conservative
GC in C programs is far more widespread in the industry than is
apparent to the eye. just a hunch, no hard numbers, but still.
> My suggestion is, to use precise marking. Assume that there is some
> reference that was forgotten to be registered. Then, this reference is on
> the stack, because conservative marking would have found it. During
> debugging, we could have a function find_unregistered_references. This
> would be called during gc after all other marking has taken place and
> would report candidates of forgotten SCM values that are on the stack but
> would be gc'd.
> => standard is precise marking.
> => debugging makes use of techniques from conservative marking.
> The gc with debugging would therefore work like this:
> 1) mark all but the stack.
> 2) scan the stack. report unmarked SCMs pointed to by stack data.
> 3) sweep
well, I certainly wouldn't want to use precise marking without such
debugging aids. but IMHO conservative marking is good enough.
> Dirk Herrmann
Paranoid schizophrenics outnumber their enemies at least two to one.