Why bother porting Guile to BDW-GC?

[ludo@gnu.org (Ludovic Courtès)]

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 .