This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: on the topic of GC.



[ warning: following are some points based on real-life experience
  with conservative GC (Boehm's).  they may be relevant or not. ]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> 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

--mike

-- 
Paranoid schizophrenics outnumber their enemies at least two to one.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]