diff options
author | Marius Vollmer <mvo@zagadka.de> | 2002-08-05 18:50:54 +0000 |
---|---|---|
committer | Marius Vollmer <mvo@zagadka.de> | 2002-08-05 18:50:54 +0000 |
commit | c5ee546dda0c74e393aca1b6c18915837e6adf7a (patch) | |
tree | 3d277077f10a3003df1bd37668c6f8c43d1b691f /doc/ref/scheme-memory.texi | |
parent | a9e40ed0d083fe84de6c969bfd341a31f1ca2b2f (diff) | |
download | guile-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.texi | 15 |
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:: |