Why bother porting Guile to BDW-GC?

Why bother porting Guile to BDW-GC?

[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 .

Re: Why bother porting Guile to BDW-GC?

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> 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.
> 

I'm all for scrapping code; here are my concerns:

- what is the performance impact?

- does BDW GC handle weak references correctly?  

- What about various (undoubtedly little used) areas where GC interacts
with the interpreter: port de-allocation, guardians, etc.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Why bother porting Guile to BDW-GC?

[Han-Wen Nienhuys]

Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>> 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.
>>
> 
> I'm all for scrapping code; here are my concerns:
> 
> - what is the performance impact?
> 
> - does BDW GC handle weak references correctly?  
> 
> - What about various (undoubtedly little used) areas where GC interacts
> with the interpreter: port de-allocation, guardians, etc.

I saw that you mentioned these in your mail.  I wonder if it feasible to 
provide backward compatibility if we move to BDW.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Why bother porting Guile to BDW-GC?

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> I'm all for scrapping code; here are my concerns:
>
> - what is the performance impact?
>
> - does BDW GC handle weak references correctly?  
>
> - What about various (undoubtedly little used) areas where GC interacts
> with the interpreter: port de-allocation, guardians, etc.

I talked about most of these in [0].

While weak hash tables are fully functional, there is a subtle
difference in how they behave that I haven't addressed yet [1].

Apart from that, the only incompatibility I know of is the lack of
`gc-live-object-stats', which can certainly be implemented but is just
slightly boring to do.  ;-)

Thanks,
Ludo'.

[0] http://thread.gmane.org/gmane.lisp.guile.devel/5946
[1] http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2465

Re: Why bother porting Guile to BDW-GC?

[Neil Jerram]

2008/11/8 Ludovic Courtès <ludo@gnu.org>:
> 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.

This all sounds pretty compelling to me.  From my point of view, you
and Han-Wen have the most knowledge of this area, and Han-Wen has one
of the most demanding applications - so if you and Han-Wen are happy
to go ahead, I'm happy too.

Just in case some really hard problem emerges, is it possible to
organize the development so that we could retain the option for a
while - say, a few months - to switch back?

Finally, I think we now really need a plan for how we are planning to
handle Guile releases over the next year or so.  I've been meaning to
write about this for a while... will do so in a new thread.

Regards,
      Neil

Re: Why bother porting Guile to BDW-GC?

[Ludovic Courtès]

Hi Neil!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> This all sounds pretty compelling to me.  From my point of view, you
> and Han-Wen have the most knowledge of this area, and Han-Wen has one
> of the most demanding applications - so if you and Han-Wen are happy
> to go ahead, I'm happy too.

Great.  I hope others view these arguments as compelling, too.

> Just in case some really hard problem emerges, is it possible to
> organize the development so that we could retain the option for a
> while - say, a few months - to switch back?

I think the best we can do is keep the thing in a separate branch.  It's
already too late to have, say, a configure-time option to choose GCs
(because I did not plan to do this when I started).  It would have been
quite hard anyway since the current GC code is quite entangled with the
rest of Guile in some places.

Does that seem like a reasonable plan?

Thanks,
Ludo'.

Re: Why bother porting Guile to BDW-GC?

[Andy Wingo]

On Tue 11 Nov 2008 21:11, ludo@gnu.org (Ludovic Courtès) writes:

> I think the best we can do is keep the thing in a separate branch.

Sure.

> Does that seem like a reasonable plan?

Some benchmarking would be really nice ;-)

Like these for example:

    http://www.ccs.neu.edu/home/will/Twobit/benchmarksAbout.html

Andy
-- 
http://wingolog.org/

Re: Why bother porting Guile to BDW-GC?

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> Some benchmarking would be really nice ;-)
>
> Like these for example:
>
>     http://www.ccs.neu.edu/home/will/Twobit/benchmarksAbout.html

Yes, see, e.g.,

  http://thread.gmane.org/gmane.lisp.guile.devel/7803
  http://thread.gmane.org/gmane.lisp.guile.devel/7803/focus=7810

The GC benchmarks used by Lars Hansen in his PhD and referred to in the
above message are already in the Git tree.  I'll report about them ASAP.

Thanks,
Ludo'.

Re: Why bother porting Guile to BDW-GC?

[Ludovic Courtès]

Hello!

One more thought...

ludo@gnu.org (Ludovic Courtès) writes:

>   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:

       3g. No need to tell Guile about much memory is allocated behind
           its back, e.g., with malloc(3).  This makes
           `scm_gc_register_collectable_memory ()' and friends (info
           "(guile) Memory Blocks") no-ops.

           It also means that BDW-GC has accurate information about heap
           usage, even in the presence of third party libraries that
           can't be instrumented to use `scm_gc_malloc ()' et al.,
           allowing it to make informed decisions.

Thanks,
Ludo'.

Re: Why bother porting Guile to BDW-GC?

[Ludovic Courtès]

Hello,

I just pushed the BDW-GC branch to Savannah:

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=shortlog;h=refs/heads/boehm-demers-weiser-gc

The machinery and benchmarks I used are available under the
`gc-benchmarks' directory:

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=gc-benchmarks;hb=refs/heads/boehm-demers-weiser-gc

Thanks,
Ludo'.