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-Guile incompatibilities Date: Wed, 18 Feb 2009 23:50:33 +0100 Message-ID: <873adx1f9i.fsf@gnu.org> References: <49dd78620901031038i6f6c678o5cebc21b217374d2@mail.gmail.com> <87sknxoeie.fsf@gnu.org> <49dd78620901151625i200f1c27r39bd360d4741392@mail.gmail.com> <87ab9psfc9.fsf_-_@gnu.org> <87vdrwl92w.fsf@arudy.ossau.uklinux.net> 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 1235918231 24806 80.91.229.12 (1 Mar 2009 14:37:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Mar 2009 14:37:11 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 01 15:38: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 1LdmoE-0008Dk-Gu for guile-devel@m.gmane.org; Sun, 01 Mar 2009 15:38:26 +0100 Original-Received: from localhost ([127.0.0.1]:44078 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ldmmt-0005Ct-Io for guile-devel@m.gmane.org; Sun, 01 Mar 2009 09:37:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ldmmp-0005Bn-VE for guile-devel@gnu.org; Sun, 01 Mar 2009 09:36:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ldmmo-0005B3-CG for guile-devel@gnu.org; Sun, 01 Mar 2009 09:36:58 -0500 Original-Received: from [199.232.76.173] (port=49374 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ldmmo-0005B0-6q for guile-devel@gnu.org; Sun, 01 Mar 2009 09:36:58 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:40525 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 1Ldmmn-0006Gc-Ll for guile-devel@gnu.org; Sun, 01 Mar 2009 09:36:58 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ldmmm-0007bI-8F for guile-devel@gnu.org; Sun, 01 Mar 2009 14:36:56 +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 ; Sun, 01 Mar 2009 14:36:56 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Mar 2009 14:36:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 85 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: 30 =?iso-8859-1?Q?Pluvi=F4se?= 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.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) Cancel-Lock: sha1:1g8mPlFsxks+RBN+ste3LS5zpI4= 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:8200 Archived-At: Hi Neil, Neil Jerram writes: > Sorry for my delay in following up here... Same for me! >>>> 1. The lack of `gc-live-object-stats'. > I was actually thinking of decrementing an object type counter when an > object is collected - and having looked more at the docs I see that > that would mean using GC_register_finalizer (). However I also see > from [1] that that (having most SCM objects being finalizable) would > be very bad for the effectiveness of the GC - because of the point > that in a chain of finalizable objects, only one object (the head) is > finalized in each collection. Yes, finalization should be used sparsely. > Ultimately I think `gc-live-object-stats' can be sacrificed if need > be. If there are specific application needs for part of the > information that it provides, I would guess that they are actually for > specific object types only and could be met by using a guardian. Yes, that's right. It's just less convenient, especially when searching for a leak of unknown origin. >>>> 3. Different behavior of weak hash tables, see >>>> http://lists.gnu.org/archive/html/guile-devel/2008-11/msg00015.html . >>>> This can be fixed, but I'm unclear whether it's worth it (comments >>>> welcome!). > Yes, but at least it is a change that we can document, and we can > precisely advise application authors what they need to do if they see > this problem. Right, this may be acceptable. > Thanks for the detailed description. But this case could also be solved > by making scm_stand_in_procs doubly weak, can't it? Yes (there are doubly-weak tests in `weaks.test'). > (Also, I wonder if it could be solved by getting rid of the stand-in > thing. Why does eval-closure need 2 references to module? Sounds > like it might be a case of design rot.) Indeed, there may be room for improvement here. :-) > Finally, another concern from [1] is "Cycles involving one or more > finalizable objects are never finalized." Given that, can our > guardians still work? You mentioned in another email about "possible > guardian glitches", is this what you had in mind? What I had in mind is the various tests in `guardians.test' that end up being "unresolved" (see, e.g., http://autobuild.josefsson.org/guile/log-200902271203718687000.txt). On my machine I was actually seeing more of them. The issue is that these tests never fail, they just throw `unresolved' at worst. This is due to the fact that we use a conservative GC so if an object remains alive, it can be due to the fact that a stale reference to the object is visible on the stack, for instance. I investigated these `unresolved' test cases, which led to this patch: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=6a7489ace3f07a8d190110cd1244963526c65729 In most cases, the tests can be made to succeed instead of being unresolved by changing the code in a way that increases chances that no references to the object we expect to die are left on the stack. However, the "g2-garbage saved" is clearly a bug, as explained in the commit above. OTOH, this use case is probably not representative of any real-world application, so I wouldn't worry about it. Besides, it would be possible for an application to create a cycle of guardians, which would prevent them from being GC'd, as you noted. Similarly, an application could create mutually referenced SMOBs, both of which have a `free ()' procedure; these could not be GC'd either. But again, that sounds rather unrealistic IMO. What do you think? Thanks, Ludo'.