From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Weak references and GC Date: Wed, 07 Sep 2005 23:43:29 +0100 Message-ID: <873bogsdm6.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 1126133573 19460 80.91.229.2 (7 Sep 2005 22:52:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2005 22:52:53 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Sep 08 00:52:45 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ED8ko-00045D-FI for guile-user@m.gmane.org; Thu, 08 Sep 2005 00:50:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ED8ke-0004Mv-CE for guile-user@m.gmane.org; Wed, 07 Sep 2005 18:50:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ED8jp-00047a-HL for guile-user@gnu.org; Wed, 07 Sep 2005 18:49:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ED8ho-0003VC-60 for guile-user@gnu.org; Wed, 07 Sep 2005 18:47:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ED8hn-0003DI-0R for guile-user@gnu.org; Wed, 07 Sep 2005 18:47:47 -0400 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ED8iA-0002mm-Bn for guile-user@gnu.org; Wed, 07 Sep 2005 18:48:10 -0400 Original-Received: from laruns (host81-130-141-16.in-addr.btopenworld.com [81.130.141.16]) by mail3.uklinux.net (Postfix) with ESMTP id A9BAE409FD8 for ; Wed, 7 Sep 2005 22:43:42 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id CA52B6F71C for ; Wed, 7 Sep 2005 23:43:29 +0100 (BST) Original-To: Guile Users User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4728 Archived-At: I'm having trouble with lists (actually source code expressions) that are weakly stored in several places and never being GC'd. I wondered if anyone on the list might be able to spot a problem in the following description. This is to do with my work on breakpoints, so each list here is a read code expression that the user wants to set a breakpoint on. Each such list is stored: - in the source weak hash (scm_source_whash), which is used for storing source properties, including the breakpoint flag - in a weak hash (created by make-object-property) that I use for mapping each list to my breakpoint object - in a guardian (greedy, because I'm using Guile 1.6 and greedy is the default there), so I can discover when the list is GC'able - as an element in a weak vector which hangs off the breakpoint object, so I can reference from the breakpoint to the source expression. These should all be weak references, but it appears that the list is never GC'd - by which I mean that - the guardian never returns the list to me when I call it - the relevant weak hash and vector cells never disappear (or change to #f). Any ideas? I'm pretty certain that the list is GC'able apart from these weak references. I wonder about the details of the interaction between the guardian and the weak references. What I would like to happen is this: - The first time that the list is deemed to be GC'able, the guardian is flagged to return it (when called), and the list then becomes non-GC'able. The weak hash and vector cells should _not_ be cleared at this point. - Some time after the guardian has been called, and dropped the list reference, the GC is run again. The list is deemed to be GC'able again, and this time there is no guardian, so the weak hash and vector cells are cleared and the list is freed. Does anyone know if this matches what the code implements? (I'm not suggesting that it doesn't - I haven't bothered to look and try to work it out yet.) Final question: are there any cunning techniques for debugging why an object is not GC'd? Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user