As explained above, the
SCM type can represent all Scheme values.
Some values fit entirely into a
SCM value (such as small
integers), but other values require additional storage in the heap (such
as strings and vectors). This additional storage is managed
automatically by Guile. You don’t need to explicitly deallocate it
SCM value is no longer used.
Two things must be guaranteed so that Guile is able to manage the storage automatically: it must know about all blocks of memory that have ever been allocated for Scheme values, and it must know about all Scheme values that are still being used. Given this knowledge, Guile can periodically free all blocks that have been allocated but are not used by any active Scheme values. This activity is called garbage collection.
Guile’s garbage collector will automatically discover references to
SCM objects that originate in global variables, static data
sections, function arguments or local variables on the C and Scheme
stacks, and values in machine registers. Other references to
objects, such as those in other random data structures in the C heap
that contain fields of type
SCM, can be made visible to the
garbage collector by calling the functions
scm_permanent_object. Collectively, these values form the “root
set” of garbage collection; any value on the heap that is referenced
directly or indirectly by a member of the root set is preserved, and all
other objects are eligible for reclamation.
The Scheme stack and heap are scanned precisely; that is to say, Guile
knows about all inter-object pointers on the Scheme stack and heap.
This is not the case, unfortunately, for pointers on the C stack and
static data segment. For this reason we have to scan the C stack and
static data segment conservatively; any value that looks like a
pointer to a GC-managed object is treated as such, whether it actually
is a reference or not. Thus, scanning the C stack and static data
segment is guaranteed to find all actual references, but it might also
find words that only accidentally look like references. These “false
positives” might keep
SCM objects alive that would otherwise be
considered dead. While this might waste memory, keeping an object
around longer than it strictly needs to is harmless. This is why this
technique is called “conservative garbage collection”. In practice,
the wasted memory seems to be no problem, as the static C root set is
almost always finite and small, given that the Scheme stack is separate
from the C stack.
The stack of every thread is scanned in this way and the registers of the CPU and all other memory locations where local variables or function parameters might show up are included in this scan as well.
The consequence of the conservative scanning is that you can just
declare local variables and function parameters of type
be sure that the garbage collector will not free the corresponding
However, a local variable or function parameter is only protected as
long as it is really on the stack (or in some register). As an
optimization, the C compiler might reuse its location for some other
value and the
SCM object would no longer be protected. Normally,
this leads to exactly the right behavior: the compiler will only
overwrite a reference when it is no longer needed and thus the object
becomes unprotected precisely when the reference disappears, just as
There are situations, however, where a
SCM object needs to be
around longer than its reference from a local variable or function
parameter. This happens, for example, when you retrieve some pointer
from a foreign object and work with that pointer directly. The
reference to the
SCM foreign object might be dead after the
pointer has been retrieved, but the pointer itself (and the memory
pointed to) is still in use and thus the foreign object must be
protected. The compiler does not know about this connection and might
SCM reference too early.
To get around this problem, you can use
and its cousins. It will keep the compiler from overwriting the
reference. See Foreign Object Memory Management.