[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
6.18.2.1 Upgrading from scm_must_malloc et al.
Version 1.6 of Guile and earlier did not have the functions from the
previous section. In their place, it had the functions
scm_must_malloc
, scm_must_realloc
and
scm_must_free
. This section explains why we want you to stop
using them, and how to do this.
The functions scm_must_malloc
and scm_must_realloc
behaved like scm_gc_malloc
and scm_gc_realloc
do now,
respectively. They would inform the GC about the newly allocated
memory via the internal equivalent of
scm_gc_register_allocation
. However,
scm_must_free
did not unregister the memory it was about to
free. The usual way to unregister memory was to return its size from
a smob free function.
This disconnectedness of the actual freeing of memory and reporting
this to the GC proved to be bad in practice. It was easy to make
mistakes and report the wrong size because allocating and freeing was
not done with symmetric code, and because it is cumbersome to compute
the total size of nested data structures that were freed with multiple
calls to scm_must_free
. Additionally, there was no equivalent
to scm_malloc
, and it was tempting to just use
scm_must_malloc
and never to tell the GC that the memory has
been freed.
The effect was that the internal statistics kept by the GC drifted out of sync with reality and could even overflow in long running programs. When this happened, the result was a dramatic increase in (senseless) GC activity which would effectively stop the program dead.
The functions scm_done_malloc
and scm_done_free
were
introduced to help restore balance to the force, but existing bugs did
not magically disappear, of course.
Therefore we decided to force everybody to review their code by deprecating the existing functions and introducing new ones in their place that are hopefully easier to use correctly.
For every use of scm_must_malloc
you need to decide whether to
use scm_malloc
or scm_gc_malloc
in its place. When the
memory block is not part of a smob or some other Scheme object whose
lifetime is ultimately managed by the garbage collector, use
scm_malloc
and free
. When it is part of a smob, use
scm_gc_malloc
and change the smob free function to use
scm_gc_free
instead of scm_must_free
or free
and
make it return zero.
The important thing is to always pair scm_malloc
with
free
; and to always pair scm_gc_malloc
with
scm_gc_free
.
The same reasoning applies to scm_must_realloc
and
scm_realloc
versus scm_gc_realloc
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on April 20, 2013 using texi2html 5.0.