summaryrefslogtreecommitdiff
path: root/doc/ref/scheme-memory.texi
diff options
context:
space:
mode:
authorMarius Vollmer <mvo@zagadka.de>2002-08-05 18:50:54 +0000
committerMarius Vollmer <mvo@zagadka.de>2002-08-05 18:50:54 +0000
commitc5ee546dda0c74e393aca1b6c18915837e6adf7a (patch)
tree3d277077f10a3003df1bd37668c6f8c43d1b691f /doc/ref/scheme-memory.texi
parenta9e40ed0d083fe84de6c969bfd341a31f1ca2b2f (diff)
downloadguile-c5ee546dda0c74e393aca1b6c18915837e6adf7a.tar.gz
Added an introductory blurb about GC that I had lying around.
Diffstat (limited to 'doc/ref/scheme-memory.texi')
-rw-r--r--doc/ref/scheme-memory.texi15
1 files changed, 15 insertions, 0 deletions
diff --git a/doc/ref/scheme-memory.texi b/doc/ref/scheme-memory.texi
index d6f0584c6..8f9d8e143 100644
--- a/doc/ref/scheme-memory.texi
+++ b/doc/ref/scheme-memory.texi
@@ -2,6 +2,21 @@
@node Memory Management
@chapter Memory Management and Garbage Collection
+Guile uses a @emph{garbage collector} to manage most of its objects.
+This means that the memory used to store a Scheme string, say, is
+automatically reclaimed when no one is using this string any longer.
+This can work because Guile knows enough about its objects at run-time
+to be able to trace all references between them. Thus, it can find
+all 'life' objects (objects that are still in use) by starting from a
+known set of 'root' objects and following the links that these objects
+have to other objects, and so on. The objects that are not reached by
+this recursive process can be considered 'dead' and their memory can
+be used for new objects.
+
+When you are programming in Scheme, you don't need to worry about the
+garbage collector. When programming in C, there are a few rules that
+you must follow so that the garbage collector can do its job.
+
@menu
* Garbage Collection::
* Memory Blocks::