From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Why bother porting Guile to BDW-GC? Date: Sat, 08 Nov 2008 16:58:15 +0100 Message-ID: <87skq2jjl4.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1226159927 15782 80.91.229.12 (8 Nov 2008 15:58:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Nov 2008 15:58:47 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 08 16:59:50 2008 connect(): Connection refused Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KyqDw-0006gM-TX for guile-devel@m.gmane.org; Sat, 08 Nov 2008 16:59:45 +0100 Original-Received: from localhost ([127.0.0.1]:52618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyqCp-0008Tw-Ar for guile-devel@m.gmane.org; Sat, 08 Nov 2008 10:58:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KyqCi-0008S6-B3 for guile-devel@gnu.org; Sat, 08 Nov 2008 10:58:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KyqCi-0008Re-02 for guile-devel@gnu.org; Sat, 08 Nov 2008 10:58:28 -0500 Original-Received: from [199.232.76.173] (port=48684 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyqCh-0008RN-Kq for guile-devel@gnu.org; Sat, 08 Nov 2008 10:58:27 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:39684 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KyqCh-0002sO-CV for guile-devel@gnu.org; Sat, 08 Nov 2008 10:58:27 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KyqCe-0004ME-SV for guile-devel@gnu.org; Sat, 08 Nov 2008 15:58:24 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Nov 2008 15:58:24 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Nov 2008 15:58:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 93 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 18 Brumaire an 217 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Cancel-Lock: sha1:9LU4zsnS0v9tdQLHHq0QhsXXM/0= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7811 Archived-At: 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 .