Hello Guilers!
Below are some of the points (in no particular order) that IMO can make
it worthwhile to use the Boehm-Demers-Weiser GC [0] in Guile instead of
Guile's historical GC, from an engineering viewpoint.
1. Less code to maintain, in particular less complex and non-portable
code. The current diffstat between `master' and the BDW-GC branch
is:
88 files changed, 3235 insertions(+), 7264 deletions(-)
2. Separation of concerns. No more GC code intermingled with the
Scheme implementation (see, e.g., fluids, structs, weak hash
tables). Likewise, we could focus on performance issues stemming
from Guile itself (interpreter or VM).
3. Benefit from an all-knowing GC. While Guile's GC knows only about
the stack(s), registers and "cell heap", BDW-GC knows about all of
a process' storage: stack(s), registers, the whole heap,
thread-local storage, etc.
Concrete benefits:
3a. No need for SMOB/port marking procedures.
3b. No need for SMOB/port free procedures, in cases where the
free procedure's job is only to deallocate memory.
3c. In many cases, no need for `scm_dynwind_free ()', which can
have a positive effect on execution time as setting up a
dynwind context is quite costly (function calls, memory
allocation).
3d. Fewer memory leaks, notably in cases where a forgotten
`scm_dynwind_free ()' can lead to a leak with Guile's GC.
3e. Easier, natural integration with C: `SCM' objects can be
stored anywhere, from global variables to `malloc ()'
allocated regions.
3f. Fewer application-GC interaction bugs like [2] (this
particular bug would simply not exist).
4. Topologically ordered finalization [1] is likely to help avoid bugs
in object finalizers. For instance, it alleviates the need for
hacks like G-Wrap's `aggregated' typespec [3, 4].
5. BDW-GC doesn't require cooperation from all threads to operate.
Thus, a blocking system call in one thread doesn't prevent GC
operation, for instance [5]. This makes `scm_without_guile ()'
optional.
6. Incremental/generational GC can be transparently enabled when
applications need it. The incremental mode is primarily designed
to reduce pause times (usually at the expense of increased memory
usage), which is important for (soft) real-time applications like
Snd.
The `GC_time_limit' variable allows applications to specify the
maximum time allowed for a collection; setting it to
`GC_TIME_UNLIMITED' disables incremental collection while leaving
generational collection (which I have not yet evaluated in my
measurements).
7. BDW-GC can perform parallel marking, which is going to be less
and less superfluous with the advent of multi-core machines [6].
8. BDW-GC can optionally be compiled to allow "back pointers" to be
tracked, thereby making it possible for the programmer to know
which reference caused an object to be retained [7].
9. When needed (e.g., for embedded systems), BDW-GC can be compiled
with `-DSMALL_CONFIG', which tunes it for small heap size, at the
expense of functionality loss (no incremental mode, fewer debugging
facilities).
That's it for now, but it's surely enough to start a warm (heated?)
discussion. ;-)
Thanks,
Ludo'.
[0] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
[1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html
[2] http://thread.gmane.org/gmane.lisp.guile.devel/7518
[3] http://thread.gmane.org/gmane.lisp.guile.devel/7518/focus=7527
[4] http://www.nongnu.org/g-wrap/manual/Wrapping-a-C-Function.html
[5]
http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2319
[6] http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html
[7] Manuel Serrano, Hans J. Boehm, /Understanding Memory Allocation of
Scheme Programs/,
http://www-sop.inria.fr/members/Manuel.Serrano/publi/sb-icfp00.ps.gz .
