From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: BDW-GC branch updated Date: Fri, 04 Sep 2009 19:15:37 +0200 Message-ID: <87eiqmmy12.fsf@delenn.lan> References: <87vdkle3qr.fsf@gnu.org> <87r5v9s4av.fsf@delenn.lan> <871vn95kgo.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1252084896 18381 80.91.229.12 (4 Sep 2009 17:21:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2009 17:21:36 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 04 19:21:26 2009 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 1MjcTV-0001An-PI for guile-devel@m.gmane.org; Fri, 04 Sep 2009 19:21:26 +0200 Original-Received: from localhost ([127.0.0.1]:50498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjcTV-0006SJ-5t for guile-devel@m.gmane.org; Fri, 04 Sep 2009 13:21:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjcO6-0008Qx-Ah for guile-devel@gnu.org; Fri, 04 Sep 2009 13:15:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjcO1-0008ND-QP for guile-devel@gnu.org; Fri, 04 Sep 2009 13:15:49 -0400 Original-Received: from [199.232.76.173] (port=47431 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjcO1-0008N3-F9 for guile-devel@gnu.org; Fri, 04 Sep 2009 13:15:45 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:46087) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MjcO0-0004lC-SM for guile-devel@gnu.org; Fri, 04 Sep 2009 13:15:45 -0400 Original-Received: (qmail invoked by alias); 04 Sep 2009 17:15:42 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp060) with SMTP; 04 Sep 2009 19:15:42 +0200 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX1+VD+I4teKVm+iZwqNKzNK5oh8M36vede/FCuw61D 1Ld4x+PMI28wn7 Original-Received: by nathot.lan (Postfix, from userid 121) id B2E473A69B; Fri, 4 Sep 2009 19:15:41 +0200 (CEST) Original-Received: from delenn.lan (delenn.lan [192.168.1.11]) by nathot.lan (Postfix) with ESMTP id DB14F3A695; Fri, 4 Sep 2009 19:15:39 +0200 (CEST) Original-Received: by delenn.lan (Postfix, from userid 1000) id 7914174DD9; Fri, 4 Sep 2009 19:15:38 +0200 (CEST) In-Reply-To: <871vn95kgo.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 18 Aug 2009 15:18:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:9262 Archived-At: ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andreas Rottmann writes: > >> Will going from a precise GC to BDW-GC not have drawbacks? IIRC, the PLT >> people went in the opposite direction. A quick google turned up this: >> >> http://www.cs.brown.edu/pipermail/plt-scheme/2006-June/013840.html >> >> I wonder if the reasons for switching to a precise GC listed in there >> will also apply to Guile. > > Thanks for the link! > > They write: > > There is one known problem, though, related to linked lists [Boehm, > POPL'02]. Unfortunately, we seem to hit this problem often in > practice, due to the way that threads and continuations are > implemented, and there doesn't seem to be a reliable way around it. > > The paper is "Bounding Space Usage of Conservative Garbage Collectors", > available from http://www.hpl.hp.com/personal/Hans_Boehm/gc/ . It > depicts scenarios where "false references" lead to unbounded data > retention. My interpretation of these scenarios and the "Summary" > section is that these cases are hopefully quite rare. > > Now, I don't have enough experience of long-running BDW-GC applications > to know whether it's a problem in practice. The PLT folks surely had > more experience (but with a different implementation IIUC). There are > also other schemes that use BDW-GC, such as Bigloo. > > However, it doesn't worry me as much as the current GC bugs (e.g., [0, 1]= ). > > Also, there are definite benefits to using a conservative GC for > libguile, given how tightly it can be integrated with C (e.g., [2]). > My main concern is/was that by moving to a conservatice GC, and _consequently changing the API of libguile to assume a conservative GC_ (as outlined in [2]), you get third code relying on that as well. This would make it effectively impossible to ever switch back to a precise GC without potentially breaking all third-party code using the libguile API. However, take that just as my < 2=E2=82=AC-cent ;-). Regards, Rotty --=20 Andreas Rottmann --