Mark H Weaver <m...@netris.org>: > Marko Rauhamaa <ma...@pacujo.net> writes: > >> Mark H Weaver <m...@netris.org>: >> >>> Marko Rauhamaa <ma...@pacujo.net> writes: >>> >>>> l...@gnu.org (Ludovic Courtès): >>>> >>>>> libgc knows which regions it must scan and mmap’d regions like >>>>> this are not among them. >>>> >>>> Wow, where is that documented? I would have imagined it scanned all >>>> writable RAM and CPU registers. >>> >>> It's documented here: http://www.hboehm.info/gc/gcdescr.html >> >> Please point out the sentence. > > Read the "Mark phase" section. In brief, roots are scanned from the > registers, stack(s), and static data region(s). The only other areas > scanned are heap areas specifically managed by libgc. No pointer is > considered valid unless it points to a libgc-managed heap block.
If you say so. Both libgc and Guile would benefit from explicitly mentioning (example) areas of RAM that aren't considered by GC. This page is quite dismissive: The BDW-GC “just works”, for the most part. [...] Thus, the BDW-GC uses a technique called conservative garbage collection, to make the local variable list unnecessary. [...] Obviously, such a system will occasionally retain objects that are actually garbage, and should be freed. In practice, this is not a problem. The alternative, an explicitly maintained list of local variable addresses, is effectively much less reliable, due to programmer error. Interested readers should see the BDW-GC web page at <URL: http://www.hboehm.info/gc/>, for more information. <URL: https://www.gnu.org/software/guile/manual/html_node/Conservativ e-GC.html> What you're saying points out a secondary problem that applies to Guile C programming. If you have stored Guile smob references in, say, third-party library objects, you'll need to carefully protect and unprotect them. Marko
