From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.bugs Subject: bug#9900: local vars not cleaned Date: Sun, 30 Oct 2011 14:52:48 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba1efd82ff9bd604b0846f12 X-Trace: dough.gmane.org 1319982786 13706 80.91.229.12 (30 Oct 2011 13:53:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2011 13:53:06 +0000 (UTC) To: 9900@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Oct 30 14:53:02 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RKVos-00008i-7M for guile-bugs@m.gmane.org; Sun, 30 Oct 2011 14:53:02 +0100 Original-Received: from localhost ([::1]:35762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKVor-0002ck-PW for guile-bugs@m.gmane.org; Sun, 30 Oct 2011 09:53:01 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKVoo-0002cf-FL for bug-guile@gnu.org; Sun, 30 Oct 2011 09:52:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKVom-00063C-MP for bug-guile@gnu.org; Sun, 30 Oct 2011 09:52:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKVom-000638-IF for bug-guile@gnu.org; Sun, 30 Oct 2011 09:52:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RKVqn-0003ar-PU for bug-guile@gnu.org; Sun, 30 Oct 2011 09:55:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Stefan Israelsson Tampe Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 30 Oct 2011 13:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9900 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 9900-submit@debbugs.gnu.org id=B9900.131998289813797 (code B ref 9900); Sun, 30 Oct 2011 13:55:01 +0000 Original-Received: (at 9900) by debbugs.gnu.org; 30 Oct 2011 13:54:58 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RKVqj-0003aU-Nv for submit@debbugs.gnu.org; Sun, 30 Oct 2011 09:54:57 -0400 Original-Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RKVqg-0003aM-Hu for 9900@debbugs.gnu.org; Sun, 30 Oct 2011 09:54:55 -0400 Original-Received: by iabn5 with SMTP id n5so6130486iab.3 for <9900@debbugs.gnu.org>; Sun, 30 Oct 2011 06:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6ERGaWDObqnt8GVjkoZcTfcn5M0lQdBTf5daP7C8t64=; b=t9LkBT9RuSTLkypiieWXj26GKBjA0U6iL+JaXIqw5WsW2qRk0RE30caWPHn6vpAcoT wDWhaYAWX9dNSKh8Bmq40Urr21hWCys/YwdlMvxUAwvVEWdxD/awyl7BCzhje9Zo579W fNre8qT3wa1Ufu95URLsJr5uFXYMOabT2/0Kw= Original-Received: by 10.42.151.4 with SMTP id c4mr15802730icw.39.1319982768036; Sun, 30 Oct 2011 06:52:48 -0700 (PDT) Original-Received: by 10.231.119.100 with HTTP; Sun, 30 Oct 2011 06:52:48 -0700 (PDT) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 30 Oct 2011 09:55:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5897 Archived-At: --90e6ba1efd82ff9bd604b0846f12 Content-Type: text/plain; charset=ISO-8859-1 >> This does seem to be the case Yes. I toke a code snippet and compiled to assembly. It looks like the .go file contain a specification of a program with a set of local variables where the (cons 'foo 'foo) is stored very much like the function local vars on the stack. Now there is a link somehow to this program that is alive after it has been executed and itself links to the list of local vars. This theory can be shown by doing the same thing in a new let and say (cons 'goo 'goo) afterwards for which the old local slot is used as storage. Hence at evaluation (gauardian) will show (foo . foo) but (goo . goo) will not appear due to beeing referenced by the local var slot. Now, one solution would be to have a pass of cleaning the local slots after the execution because this behavior has the potential of leading to memory leaks. The next step is to question the use of keeping the link to the program that comes from the loaded file, maybe due to cashing this is an effective strategy, but someone with greater overview of the code has to commment on this. In alles locally defined functions and variables should not be kept in the gc because it is begging to yield memory leaks. cashing locally defined functions is a bit weaker and on first sight can be a good cashing strategy. On the other hand if one implementing schemes like Ian does one can easilly have a chain of objects that has to be gc:d is a specific order and if one of these object is a local lambda gcing of the elements further down will not happen. > I disagree. While I would certainly expect it to work if I made the > reference to f weak, it would miss the point of my code entirely. Namely > to make sure that f isn't gc'd until after some other value is (hence > the weak reference to a cons, and my comment about expecting to need 2 gcs). Sorry for may blunt statement here. You seam to come from a valid way of doing your coding. My fault. /Stefan --90e6ba1efd82ff9bd604b0846f12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> This does seem to be the case

Yes. I toke a code snippet an= d compiled to assembly. It looks like the .go file contain a specification<= br>of a program with a set of local variables where the (cons 'foo '= ;foo) is stored very much like the function
local vars on the stack. Now there is a link somehow to this program that i= s alive after it has been executed
and itself links to the list of local= vars. This theory can be shown by doing the same thing in a new let
=A0and say (cons 'goo 'goo) afterwards for which the old local slot= is used as storage. Hence at evaluation
(gauardian) will show (foo . fo= o) but (goo . goo) will not appear due to beeing referenced by the local va= r slot.

Now, one solution would be to have a pass of cleaning the local slots a= fter the execution because this behavior
has the potential of leading to= memory leaks. The next step is to question the use of keeping the link to = the program
that comes from the loaded file, maybe due to cashing this is an effective = strategy, but someone with greater overview
of the code has to commment = on this. In alles locally defined functions and variables should not be kep= t in the gc because
it is begging to yield memory leaks. cashing locally defined functions is a= bit weaker and on first sight can be a good cashing strategy. On the other= hand if one implementing schemes like Ian does one can easilly have a chai= n of objects that has to be gc:d is a specific
order and if one of these object is a local lambda gcing of the elements fu= rther down will not happen.


> I disagree. While I would certa= inly expect it to work if I made the
> reference to f weak, it would miss the point of my code entirely. Name= ly
> to make sure that f isn't gc'd until after some other value is= (hence
> the weak reference to a cons, and my comment about expecting to need 2= gcs).

Sorry for may blunt statement here. You seam to come from a v= alid way of doing your coding. My fault.

/Stefan
--90e6ba1efd82ff9bd604b0846f12--