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: Re: BDW-GC branch updated Date: Sat, 05 Sep 2009 16:45:15 +0200 Message-ID: <87ljkt4fic.fsf@gnu.org> References: <87vdkle3qr.fsf@gnu.org> <87r5v9s4av.fsf@delenn.lan> <871vn95kgo.fsf@gnu.org> <87eiqmmy12.fsf@delenn.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1252161967 716 80.91.229.12 (5 Sep 2009 14:46:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Sep 2009 14:46:07 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Sep 05 16:46:00 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 1MjwWb-00034s-JW for guile-devel@m.gmane.org; Sat, 05 Sep 2009 16:45:57 +0200 Original-Received: from localhost ([127.0.0.1]:54970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjwWa-0003ry-WA for guile-devel@m.gmane.org; Sat, 05 Sep 2009 10:45:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjwWT-0003p5-Af for guile-devel@gnu.org; Sat, 05 Sep 2009 10:45:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjwWO-0003nt-Tu for guile-devel@gnu.org; Sat, 05 Sep 2009 10:45:49 -0400 Original-Received: from [199.232.76.173] (port=43823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjwWO-0003nq-O3 for guile-devel@gnu.org; Sat, 05 Sep 2009 10:45:44 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:47099) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MjwWO-0008GO-A9 for guile-devel@gnu.org; Sat, 05 Sep 2009 10:45:44 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1MjwWK-000304-PO for guile-devel@gnu.org; Sat, 05 Sep 2009 16:45:40 +0200 Original-Received: from 78.251.22.202 ([78.251.22.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Sep 2009 16:45:40 +0200 Original-Received: from ludo by 78.251.22.202 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Sep 2009 16:45:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78.251.22.202 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 19 Fructidor an 217 de la =?iso-8859-1?Q?R=E9volutio?= =?iso-8859-1?Q?n?= 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: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:rprrqgVD5HCDvt4naQLWYVHl2QI= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:9265 Archived-At: Hi, Andreas Rottmann writes: > 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. The current GC is "semi-conservative" in that it scans the C stack and the "cell heap" for pointers, but nothing beyond that. The current API is built around this assumption. BDW-GC is conservative: it scans everything, unless it's told otherwise (e.g., `GC_malloc_atomic ()'). So you're right, the BDW-GC branch does introduce API changes to take advantage of this, the most important of which being that `scm_gc_malloc ()' memory is scanned and automatically managed. It's true that going back to the current "semi-precise" GC API would be hard once we've made that change. However, using a fully conservative GC makes it much easier to interact with C, which is one of Guile's main goals as an extension language. Furthermore, the concern about the risk of excess data retention caused by conservative scanning holds as well for the current semi-conservative GC. Thus I believe the advantages of a conservative GC for Guile outweighs its presumed disadvantages. Thanks, Ludo'.