Chris Vine <vine35792...@gmail.com>: > On Fri, 21 Jul 2017 09:15:28 +0300 > Marko Rauhamaa <ma...@pacujo.net> wrote: >> 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.
I use libgc in non-Guile code. If mmapped areas are not considered for GC, I'll have to take special care. I had assumed libgc simply introspects the process's memory map and traverses anything reachable. After all, the process might be also using a secondary memory allocator based on mmap. What if you do place pointers in a mmapped region? > There is also some information at https://www.gnu.org/softwa > re/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). Which doesn't say anything explicit about mmap. Anyway, I suspect a bytearray is guaranteed to be pointerless and could be used for the desired kind of mass storage in RAM. It all hinges on the efficiency of encoding and decoding objects. As much as possible, I would like to stay in Scheme-land. Marko
