On Fri, 21 Jul 2017 09:15:28 +0300 Marko Rauhamaa <ma...@pacujo.net> wrote: > 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. > > The closest I could find is: > > * Static data region(s). In the simplest case, this is the region > between DATASTART and DATAEND, as defined in gcconfig.h. However, > in most cases, this will also involve static data regions > associated with dynamic libraries. These are identified by the > mostly platform-specific code in dyn_load.c. > > But that doesn't clearly state if mmapped regions are in or out. I > would have assumed they were in.
Since the C runtime does not store static variables in mmapped memory, I would have assumed the opposite. There is also some information at https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection.html#Garbage-Collection That states that the areas that the garbage collector scans for live objects are the areas where global and other static variables are placed, local variables (including function arguments and registers), and heap memory allocated by scm_gc_malloc() (but not memory allocated by scm_gc_malloc_pointerless() or by malloc() and cognates). If a SCM object keeps references to sub-objects residing in unscanned memory, this applies: https://www.gnu.org/software/guile/manual/html_node/Foreign-Object-Memory-Management.html#Foreign-Object-Memory-Management (and the equivalent for smobs in guile-2.0). Chris