This is the mail archive of the
guile@sourceware.cygnus.com
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: Miroslav Silovic <silovic at zesoi dot fer dot hr>
- Date: 21 Sep 1999 12:46:57 +0200
- Cc: Jim Blandy <jimb at red-bean dot com>, Michael Livshin <mike at olan dot com>, guile at sourceware dot cygnus dot com
- References: <Pine.LNX.4.10.9909211003590.1017-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> => standard is precise marking.
> => debugging makes use of techniques from conservative marking.
I like this. A lot.
Note that the main source of the heap corruption is not forgetting to
mark something - far more often, it's index overflow in malloced C
arrays (which corrupts the pointers in unrelated neighboring
datastructures, but is only discovered in a GC run). Unfortunately
these are highly nontrivial to catch. Perhaps also introduce guarded
mallocs (i.e. mallocs that allocate configurable extra space at both
sides of the array, fill it with constants (0xdeadbeef is popular :) )
and periodically check for corruption.
Currently, for SART, I'm using commercial tools instead (SPARC
Workshop), doing basically the same thing as Purify (i.e. it doctors
the code and explicitely checks *all* memory access).
--
How to eff the ineffable?