This is the mail archive of the guile@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] |
klaus.schilling@home.ivm.de writes: > > In the last posts, it was said repeatedly that the garbage collection of guile > is conservative. > > What does this mean? Is this related to conservation laws in physics (mass, > energy, momentum etc.) Is 'mark and sweep' necessarily conservative? > "Conservative garbage collection" refers to any garbage collection system that scans at least part of memory in it's entirety and treats anything that looks like a GC-controlled object as if it is one. So for example if something in the region being scanned looks like it points to a cons cell on the heap, even though it may really just be a C integer that coincidentally looks like something with a type tag, that region of memory will not be reclaimed, even though there might be no real references to it. In the case of Guile, only the C stack is scanned this way. The advantage is that Scheme objects on the C stack, i.e. currently being operated on by code written in C, will automatically be protected against gc. The disadvantage is that, in theory, it is possible to have an unbounded memory leak if something on the stack aliases something in the middle of a list. In practice this never occurs, especially not when scanning only the stack. "Mark and sweep" does not necessarily have to be conservative, for instance it is possible to use the global environment as the only root for marking. Nor does conservative gc necessarily need to be "mark and sweep", although I can't imagine it working very well with "stop and copy". > What alternatives would there be to conservative garbage collection? R*RS > doesn't recommend any particular gc strategy at all, so may be other scheme > implementations act differently, even more Common Lisp engines. > For Scheme implementations, conservative garbage collection really only refers to the interaction of the implementation with normally non-garbage-collected languages such as C. One alternative is to provide special primitives to C code to explicitly mark objects on the stack; I believe GNU Emacs does things this way currently. This makes thinkgs considerably more complex for C code, but avoids the infinitesimal possibility of an unbounded memory leak. - Maciej