api-memory.texi 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437
  1. @c -*-texinfo-*-
  2. @c This is part of the GNU Guile Reference Manual.
  3. @c Copyright (C) 1996, 1997, 2000-2004, 2009, 2010, 2012-2016
  4. @c Free Software Foundation, Inc.
  5. @c See the file guile.texi for copying conditions.
  6. @node Memory Management
  7. @section Memory Management and Garbage Collection
  8. Guile uses a @emph{garbage collector} to manage most of its objects.
  9. While the garbage collector is designed to be mostly invisible, you
  10. sometimes need to interact with it explicitly.
  11. See @ref{Garbage Collection} for a general discussion of how garbage
  12. collection relates to using Guile from C.
  13. @menu
  14. * Garbage Collection Functions::
  15. * Memory Blocks::
  16. * Weak References::
  17. * Guardians::
  18. @end menu
  19. @node Garbage Collection Functions
  20. @subsection Function related to Garbage Collection
  21. @deffn {Scheme Procedure} gc
  22. @deffnx {C Function} scm_gc ()
  23. Finds all of the ``live'' @code{SCM} objects and reclaims for further
  24. use those that are no longer accessible. You normally don't need to
  25. call this function explicitly. Its functionality is invoked
  26. automatically as needed.
  27. @end deffn
  28. @deftypefn {C Function} SCM scm_gc_protect_object (SCM @var{obj})
  29. Protects @var{obj} from being freed by the garbage collector, when it
  30. otherwise might be. When you are done with the object, call
  31. @code{scm_gc_unprotect_object} on the object. Calls to
  32. @code{scm_gc_protect_object}/@code{scm_gc_unprotect_object} can be nested, and
  33. the object remains protected until it has been unprotected as many times
  34. as it was protected. It is an error to unprotect an object more times
  35. than it has been protected. Returns the SCM object it was passed.
  36. Note that storing @var{obj} in a C global variable has the same
  37. effect@footnote{In Guile up to version 1.8, C global variables were not
  38. visited by the garbage collector in the mark phase; hence,
  39. @code{scm_gc_protect_object} was the only way in C to prevent a Scheme
  40. object from being freed.}.
  41. @end deftypefn
  42. @deftypefn {C Function} SCM scm_gc_unprotect_object (SCM @var{obj})
  43. Unprotects an object from the garbage collector which was protected by
  44. @code{scm_gc_unprotect_object}. Returns the SCM object it was passed.
  45. @end deftypefn
  46. @deftypefn {C Function} SCM scm_permanent_object (SCM @var{obj})
  47. Similar to @code{scm_gc_protect_object} in that it causes the
  48. collector to always mark the object, except that it should not be
  49. nested (only call @code{scm_permanent_object} on an object once), and
  50. it has no corresponding unpermanent function. Once an object is
  51. declared permanent, it will never be freed. Returns the SCM object it
  52. was passed.
  53. @end deftypefn
  54. @c NOTE: The varargs scm_remember_upto_here is deliberately not
  55. @c documented, because we don't think it can be implemented as a nice
  56. @c inline compiler directive or asm block. New _3, _4 or whatever
  57. @c forms could certainly be added though, if needed.
  58. @deftypefn {C Macro} void scm_remember_upto_here_1 (SCM obj)
  59. @deftypefnx {C Macro} void scm_remember_upto_here_2 (SCM obj1, SCM obj2)
  60. Create a reference to the given object or objects, so they're certain
  61. to be present on the stack or in a register and hence will not be
  62. freed by the garbage collector before this point.
  63. Note that these functions can only be applied to ordinary C local
  64. variables (ie.@: ``automatics''). Objects held in global or static
  65. variables or some malloced block or the like cannot be protected with
  66. this mechanism.
  67. @end deftypefn
  68. @deffn {Scheme Procedure} gc-stats
  69. @deffnx {C Function} scm_gc_stats ()
  70. Return an association list of statistics about Guile's current
  71. use of storage.
  72. @end deffn
  73. @deffn {Scheme Procedure} gc-live-object-stats
  74. @deffnx {C Function} scm_gc_live_object_stats ()
  75. Return an alist of statistics of the current live objects.
  76. @end deffn
  77. @deftypefun void scm_gc_mark (SCM @var{x})
  78. Mark the object @var{x}, and recurse on any objects @var{x} refers to.
  79. If @var{x}'s mark bit is already set, return immediately. This function
  80. must only be called during the mark-phase of garbage collection,
  81. typically from a smob @emph{mark} function.
  82. @end deftypefun
  83. @node Memory Blocks
  84. @subsection Memory Blocks
  85. @cindex automatically-managed memory
  86. @cindex GC-managed memory
  87. @cindex conservative garbage collection
  88. In C programs, dynamic management of memory blocks is normally done
  89. with the functions malloc, realloc, and free. Guile has additional
  90. functions for dynamic memory allocation that are integrated into the
  91. garbage collector and the error reporting system.
  92. Memory blocks that are associated with Scheme objects (for example a
  93. foreign object) should be allocated with @code{scm_gc_malloc} or
  94. @code{scm_gc_malloc_pointerless}. These two functions will either
  95. return a valid pointer or signal an error. Memory blocks allocated this
  96. way may be released explicitly; however, this is not strictly needed,
  97. and we recommend @emph{not} calling @code{scm_gc_free}. All memory
  98. allocated with @code{scm_gc_malloc} or @code{scm_gc_malloc_pointerless}
  99. is automatically reclaimed when the garbage collector no longer sees any
  100. live reference to it@footnote{In Guile up to version 1.8, memory
  101. allocated with @code{scm_gc_malloc} @emph{had} to be freed with
  102. @code{scm_gc_free}.}.
  103. When garbage collection occurs, Guile will visit the words in memory
  104. allocated with @code{scm_gc_malloc}, looking for live pointers. This
  105. means that if @code{scm_gc_malloc}-allocated memory contains a pointer
  106. to some other part of the memory, the garbage collector notices it and
  107. prevents it from being reclaimed@footnote{In Guile up to 1.8, memory
  108. allocated with @code{scm_gc_malloc} was @emph{not} visited by the
  109. collector in the mark phase. Consequently, the GC had to be told
  110. explicitly about pointers to live objects contained in the memory block,
  111. e.g., @i{via} SMOB mark functions (@pxref{Smobs,
  112. @code{scm_set_smob_mark}})}. Conversely, memory allocated with
  113. @code{scm_gc_malloc_pointerless} is assumed to be ``pointer-less'' and
  114. is not scanned for pointers.
  115. For memory that is not associated with a Scheme object, you can use
  116. @code{scm_malloc} instead of @code{malloc}. Like
  117. @code{scm_gc_malloc}, it will either return a valid pointer or signal
  118. an error. However, it will not assume that the new memory block can
  119. be freed by a garbage collection. The memory must be explicitly freed
  120. with @code{free}.
  121. There is also @code{scm_gc_realloc} and @code{scm_realloc}, to be used
  122. in place of @code{realloc} when appropriate, and @code{scm_gc_calloc}
  123. and @code{scm_calloc}, to be used in place of @code{calloc} when
  124. appropriate.
  125. The function @code{scm_dynwind_free} can be useful when memory should be
  126. freed with libc's @code{free} when leaving a dynwind context,
  127. @xref{Dynamic Wind}.
  128. @deftypefn {C Function} {void *} scm_malloc (size_t @var{size})
  129. @deftypefnx {C Function} {void *} scm_calloc (size_t @var{size})
  130. Allocate @var{size} bytes of memory and return a pointer to it. When
  131. @var{size} is 0, return @code{NULL}. When not enough memory is
  132. available, signal an error. This function runs the GC to free up some
  133. memory when it deems it appropriate.
  134. The memory is allocated by the libc @code{malloc} function and can be
  135. freed with @code{free}. There is no @code{scm_free} function to go
  136. with @code{scm_malloc} to make it easier to pass memory back and forth
  137. between different modules.
  138. The function @code{scm_calloc} is similar to @code{scm_malloc}, but
  139. initializes the block of memory to zero as well.
  140. These functions will (indirectly) call
  141. @code{scm_gc_register_allocation}.
  142. @end deftypefn
  143. @deftypefn {C Function} {void *} scm_realloc (void *@var{mem}, size_t @var{new_size})
  144. Change the size of the memory block at @var{mem} to @var{new_size} and
  145. return its new location. When @var{new_size} is 0, this is the same
  146. as calling @code{free} on @var{mem} and @code{NULL} is returned. When
  147. @var{mem} is @code{NULL}, this function behaves like @code{scm_malloc}
  148. and allocates a new block of size @var{new_size}.
  149. When not enough memory is available, signal an error. This function
  150. runs the GC to free up some memory when it deems it appropriate.
  151. This function will call @code{scm_gc_register_allocation}.
  152. @end deftypefn
  153. @deftypefn {C Function} {void *} scm_gc_malloc (size_t @var{size}, const char *@var{what})
  154. @deftypefnx {C Function} {void *} scm_gc_malloc_pointerless (size_t @var{size}, const char *@var{what})
  155. @deftypefnx {C Function} {void *} scm_gc_realloc (void *@var{mem}, size_t @var{old_size}, size_t @var{new_size}, const char *@var{what});
  156. @deftypefnx {C Function} {void *} scm_gc_calloc (size_t @var{size}, const char *@var{what})
  157. Allocate @var{size} bytes of automatically-managed memory. The memory
  158. is automatically freed when no longer referenced from any live memory
  159. block.
  160. When garbage collection occurs, Guile will visit the words in memory
  161. allocated with @code{scm_gc_malloc} or @code{scm_gc_calloc}, looking for
  162. pointers to other memory allocations that are managed by the GC. In
  163. contrast, memory allocated by @code{scm_gc_malloc_pointerless} is not
  164. scanned for pointers.
  165. The @code{scm_gc_realloc} call preserves the ``pointerlessness'' of the
  166. memory area pointed to by @var{mem}. Note that you need to pass the old
  167. size of a reallocated memory block as well. See below for a motivation.
  168. @end deftypefn
  169. @deftypefn {C Function} void scm_gc_free (void *@var{mem}, size_t @var{size}, const char *@var{what})
  170. Explicitly free the memory block pointed to by @var{mem}, which was
  171. previously allocated by one of the above @code{scm_gc} functions. This
  172. function is almost always unnecessary, except for codebases that still
  173. need to compile on Guile 1.8.
  174. Note that you need to explicitly pass the @var{size} parameter. This
  175. is done since it should normally be easy to provide this parameter
  176. (for memory that is associated with GC controlled objects) and help keep
  177. the memory management overhead very low. However, in Guile 2.x,
  178. @var{size} is always ignored.
  179. @end deftypefn
  180. @deftypefn {C Function} void scm_gc_register_allocation (size_t @var{size})
  181. Informs the garbage collector that @var{size} bytes have been allocated,
  182. which the collector would otherwise not have known about.
  183. In general, Scheme will decide to collect garbage only after some amount
  184. of memory has been allocated. Calling this function will make the
  185. Scheme garbage collector know about more allocation, and thus run more
  186. often (as appropriate).
  187. It is especially important to call this function when large unmanaged
  188. allocations, like images, may be freed by small Scheme allocations, like
  189. foreign objects.
  190. @end deftypefn
  191. @deftypefn {C Function} void scm_dynwind_free (void *mem)
  192. Equivalent to @code{scm_dynwind_unwind_handler (free, @var{mem},
  193. SCM_F_WIND_EXPLICITLY)}. That is, the memory block at @var{mem} will be
  194. freed (using @code{free} from the C library) when the current dynwind is
  195. left.
  196. @end deftypefn
  197. @deffn {Scheme Procedure} malloc-stats
  198. Return an alist ((@var{what} . @var{n}) ...) describing number
  199. of malloced objects.
  200. @var{what} is the second argument to @code{scm_gc_malloc},
  201. @var{n} is the number of objects of that type currently
  202. allocated.
  203. This function is only available if the @code{GUILE_DEBUG_MALLOC}
  204. preprocessor macro was defined when Guile was compiled.
  205. @end deffn
  206. @node Weak References
  207. @subsection Weak References
  208. [FIXME: This chapter is based on Mikael Djurfeldt's answer to a
  209. question by Michael Livshin. Any mistakes are not theirs, of course. ]
  210. Weak references let you attach bookkeeping information to data so that
  211. the additional information automatically disappears when the original
  212. data is no longer in use and gets garbage collected. In a weak key hash,
  213. the hash entry for that key disappears as soon as the key is no longer
  214. referenced from anywhere else. For weak value hashes, the same happens
  215. as soon as the value is no longer in use. Entries in a doubly weak hash
  216. disappear when either the key or the value are not used anywhere else
  217. anymore.
  218. Object properties offer the same kind of functionality as weak key
  219. hashes in many situations. (@pxref{Object Properties})
  220. Here's an example (a little bit strained perhaps, but one of the
  221. examples is actually used in Guile):
  222. Assume that you're implementing a debugging system where you want to
  223. associate information about filename and position of source code
  224. expressions with the expressions themselves.
  225. Hashtables can be used for that, but if you use ordinary hash tables
  226. it will be impossible for the scheme interpreter to "forget" old
  227. source when, for example, a file is reloaded.
  228. To implement the mapping from source code expressions to positional
  229. information it is necessary to use weak-key tables since we don't want
  230. the expressions to be remembered just because they are in our table.
  231. To implement a mapping from source file line numbers to source code
  232. expressions you would use a weak-value table.
  233. To implement a mapping from source code expressions to the procedures
  234. they constitute a doubly-weak table has to be used.
  235. @menu
  236. * Weak hash tables::
  237. * Weak vectors::
  238. @end menu
  239. @node Weak hash tables
  240. @subsubsection Weak hash tables
  241. @deffn {Scheme Procedure} make-weak-key-hash-table [size]
  242. @deffnx {Scheme Procedure} make-weak-value-hash-table [size]
  243. @deffnx {Scheme Procedure} make-doubly-weak-hash-table [size]
  244. @deffnx {C Function} scm_make_weak_key_hash_table (size)
  245. @deffnx {C Function} scm_make_weak_value_hash_table (size)
  246. @deffnx {C Function} scm_make_doubly_weak_hash_table (size)
  247. Return a weak hash table with @var{size} buckets. As with any
  248. hash table, choosing a good size for the table requires some
  249. caution.
  250. You can modify weak hash tables in exactly the same way you would modify
  251. regular hash tables, with the exception of the routines that act on
  252. handles. Weak tables have a different implementation behind the scenes
  253. that doesn't have handles. @pxref{Hash Tables}, for more on
  254. @code{hashq-ref} et al.
  255. @end deffn
  256. Note that in a weak-key hash table, the reference to the value is
  257. strong. This means that if the value references the key, even
  258. indirectly, the key will never be collected, which can lead to a memory
  259. leak. The reverse is true for weak value tables.
  260. @deffn {Scheme Procedure} weak-key-hash-table? obj
  261. @deffnx {Scheme Procedure} weak-value-hash-table? obj
  262. @deffnx {Scheme Procedure} doubly-weak-hash-table? obj
  263. @deffnx {C Function} scm_weak_key_hash_table_p (obj)
  264. @deffnx {C Function} scm_weak_value_hash_table_p (obj)
  265. @deffnx {C Function} scm_doubly_weak_hash_table_p (obj)
  266. Return @code{#t} if @var{obj} is the specified weak hash
  267. table. Note that a doubly weak hash table is neither a weak key
  268. nor a weak value hash table.
  269. @end deffn
  270. @node Weak vectors
  271. @subsubsection Weak vectors
  272. @deffn {Scheme Procedure} make-weak-vector size [fill]
  273. @deffnx {C Function} scm_make_weak_vector (size, fill)
  274. Return a weak vector with @var{size} elements. If the optional
  275. argument @var{fill} is given, all entries in the vector will be
  276. set to @var{fill}. The default value for @var{fill} is the
  277. empty list.
  278. @end deffn
  279. @deffn {Scheme Procedure} weak-vector elem @dots{}
  280. @deffnx {Scheme Procedure} list->weak-vector l
  281. @deffnx {C Function} scm_weak_vector (l)
  282. Construct a weak vector from a list: @code{weak-vector} uses
  283. the list of its arguments while @code{list->weak-vector} uses
  284. its only argument @var{l} (a list) to construct a weak vector
  285. the same way @code{list->vector} would.
  286. @end deffn
  287. @deffn {Scheme Procedure} weak-vector? obj
  288. @deffnx {C Function} scm_weak_vector_p (obj)
  289. Return @code{#t} if @var{obj} is a weak vector.
  290. @end deffn
  291. @deffn {Scheme Procedure} weak-vector-ref wvect k
  292. @deffnx {C Function} scm_weak_vector_ref (wvect, k)
  293. Return the @var{k}th element of the weak vector @var{wvect}, or
  294. @code{#f} if that element has been collected.
  295. @end deffn
  296. @deffn {Scheme Procedure} weak-vector-set! wvect k elt
  297. @deffnx {C Function} scm_weak_vector_set_x (wvect, k, elt)
  298. Set the @var{k}th element of the weak vector @var{wvect} to @var{elt}.
  299. @end deffn
  300. @node Guardians
  301. @subsection Guardians
  302. Guardians provide a way to be notified about objects that would
  303. otherwise be collected as garbage. Guarding them prevents the objects
  304. from being collected and cleanup actions can be performed on them, for
  305. example.
  306. See R. Kent Dybvig, Carl Bruggeman, and David Eby (1993) "Guardians in
  307. a Generation-Based Garbage Collector". ACM SIGPLAN Conference on
  308. Programming Language Design and Implementation, June 1993.
  309. @deffn {Scheme Procedure} make-guardian
  310. @deffnx {C Function} scm_make_guardian ()
  311. Create a new guardian. A guardian protects a set of objects from
  312. garbage collection, allowing a program to apply cleanup or other
  313. actions.
  314. @code{make-guardian} returns a procedure representing the guardian.
  315. Calling the guardian procedure with an argument adds the argument to
  316. the guardian's set of protected objects. Calling the guardian
  317. procedure without an argument returns one of the protected objects
  318. which are ready for garbage collection, or @code{#f} if no such object
  319. is available. Objects which are returned in this way are removed from
  320. the guardian.
  321. You can put a single object into a guardian more than once and you can
  322. put a single object into more than one guardian. The object will then
  323. be returned multiple times by the guardian procedures.
  324. An object is eligible to be returned from a guardian when it is no
  325. longer referenced from outside any guardian.
  326. There is no guarantee about the order in which objects are returned
  327. from a guardian. If you want to impose an order on finalization
  328. actions, for example, you can do that by keeping objects alive in some
  329. global data structure until they are no longer needed for finalizing
  330. other objects.
  331. Being an element in a weak vector, a key in a hash table with weak
  332. keys, or a value in a hash table with weak values does not prevent an
  333. object from being returned by a guardian. But as long as an object
  334. can be returned from a guardian it will not be removed from such a
  335. weak vector or hash table. In other words, a weak link does not
  336. prevent an object from being considered collectable, but being inside
  337. a guardian prevents a weak link from being broken.
  338. A key in a weak key hash table can be thought of as having a strong
  339. reference to its associated value as long as the key is accessible.
  340. Consequently, when the key is only accessible from within a guardian,
  341. the reference from the key to the value is also considered to be
  342. coming from within a guardian. Thus, if there is no other reference
  343. to the value, it is eligible to be returned from a guardian.
  344. @end deffn
  345. @c Local Variables:
  346. @c TeX-master: "guile.texi"
  347. @c End: