From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile + Boehm GC: First Remarks Date: Thu, 01 Jun 2006 09:55:58 +0200 Organization: LAAS-CNRS Message-ID: <87ac8x8g35.fsf@laas.fr> References: <877j42r32u.fsf@laas.fr> <87irnmt0nk.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1149148593 31382 80.91.229.2 (1 Jun 2006 07:56:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2006 07:56:33 +0000 (UTC) Cc: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jun 01 09:56:29 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fli2e-0007fs-Cn for guile-devel@m.gmane.org; Thu, 01 Jun 2006 09:56:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fli2d-0001PR-UO for guile-devel@m.gmane.org; Thu, 01 Jun 2006 03:56:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fli2Y-0001P8-Kn for guile-devel@gnu.org; Thu, 01 Jun 2006 03:56:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fli2X-0001Ow-Do for guile-devel@gnu.org; Thu, 01 Jun 2006 03:56:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fli2X-0001Ot-9C for guile-devel@gnu.org; Thu, 01 Jun 2006 03:56:21 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Fli8j-0008FB-9h for guile-devel@gnu.org; Thu, 01 Jun 2006 04:02:45 -0400 Original-Received: by laas.laas.fr (8.13.6/8.13.4) with SMTP id k517uHGn015607; Thu, 1 Jun 2006 09:56:19 +0200 (CEST) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 13 Prairial an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , Guile-Devel In-Reply-To: <87irnmt0nk.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 31 May 2006 21:11:27 +0100") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:5951 Archived-At: Hi, Neil Jerram writes: > Fascinating! Assuming we can resolve the details you have listed, > what are the other high-level pros/cons, apart from performance? Does > this mean we would discard all Guile's own GC code? Also, is Boehm GC > as sophisticated as the generational GC ideas that people have talked > over the last year about adding Guile, or can we expect future Boehm > GC development to cover this? As Han-Wen said, BGC is generational. More details are available from: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html For Guile, the main advantage is maintainability: using BGC significantly reduces code complexity (i.e., it removes the hardest-to-read parts of the code, it disentangles GC code from functional code), it may improve portability, and it has the potential to improve performance --- although that potential hasn't shown up yet. ;-) >>From a technical viewpoint, it is much, much easier to use, and avoids many common programming errors: unless otherwise specified, every register and every piece of memory is scanned for pointers, not only the heap (however, only heap regions allocated via the GC allocation routines are scanned). Also, it periodically clears the unused part of the stack, which may help avoid certain leaks (as the eval-stack leak described in [0]). Thanks, Ludovic. [0] http://lists.gnu.org/archive/html/guile-devel/2005-11/msg00047.html _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel