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.devel Subject: memory leak Date: Sun, 23 Oct 2011 19:11:03 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd5712c1da74c04affa64d4 X-Trace: dough.gmane.org 1319389875 11764 80.91.229.12 (23 Oct 2011 17:11:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 23 Oct 2011 17:11:15 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 23 19:11:10 2011 Return-path: Envelope-to: guile-devel@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 1RI1Zl-00020a-RL for guile-devel@m.gmane.org; Sun, 23 Oct 2011 19:11:10 +0200 Original-Received: from localhost ([::1]:45413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RI1Zk-0000ws-UY for guile-devel@m.gmane.org; Sun, 23 Oct 2011 13:11:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RI1Zh-0000wT-Nm for guile-devel@gnu.org; Sun, 23 Oct 2011 13:11:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RI1Zg-0003KZ-BO for guile-devel@gnu.org; Sun, 23 Oct 2011 13:11:05 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:51704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RI1Zg-0003KL-8M for guile-devel@gnu.org; Sun, 23 Oct 2011 13:11:04 -0400 Original-Received: by iagf6 with SMTP id f6so8637868iag.0 for ; Sun, 23 Oct 2011 10:11:03 -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=pjKNotFnwcSUI792/gQsOCF99NIrqoYnQtyxbXFM0U4=; b=ZI8/1MNPtK1cIN3jdCB9fGXqYXBy8pMVXpN9ZsPYFWj4n1AKOPUjPeAEBOFPAUanbz MzdyGuX3q+HBZNCBI4+IkbgWNQWivWyx0MjTJrO+4pWTUdRBIJQgoo91JMbA53XOczCC yx+huCVPNqk7KlmTLT0dcGbUCQ3TCLDoGVoZQ= Original-Received: by 10.231.63.209 with SMTP id c17mr9282759ibi.65.1319389863191; Sun, 23 Oct 2011 10:11:03 -0700 (PDT) Original-Received: by 10.231.48.135 with HTTP; Sun, 23 Oct 2011 10:11:03 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12854 Archived-At: --000e0cd5712c1da74c04affa64d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, Regarding the observed leaks in guile. A question is if this is due to some kind of memory fragmentation more then a pure memory leak. In the observed bug where in constructing and droping threads, one can see that memory leaks dramatically and 2Gig is consumed after about 2000 constructed threads. If one issue a direct call to scm_gc att the allocation of the stack the problem becomes much less dramatic. It looks like gc is run to free a certain amount of memory but not taking care of the alignmnent so that the collection phase lead to the right amount but due to fragmentation the memory is not contiguous. Hence more memory is allocated and the system seams to go into a state of keeping freeable memory and allocating new memory in about the same speed. I would try to do an experiment where one allocates the stack with scm_malloc and free it with free and attach mark and finilizing functions to see if the problem disapears. How to do such a test? Any suggestion? Regards Stefan --000e0cd5712c1da74c04affa64d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Regarding the observed leaks in guile. A question is if this is = due to some kind of memory fragmentation more then
a pure memory leak. I= n the observed bug where in constructing and droping threads, one can see t= hat memory leaks dramatically
and 2Gig is consumed after about 2000 constructed threads. If one issue a d= irect call to scm_gc att the allocation of the stack
the problem becomes= much less dramatic. It looks like gc is run to free a certain amount of me= mory but not taking care of the alignmnent
so that the collection phase lead to the right amount but due to fragmentat= ion the memory is not contiguous. Hence more memory is
allocated and th= e system seams to go into a state of keeping freeable memory and allocating= new memory in about the same speed.

I would try to do an experiment where one allocates the stack with scm_= malloc and free it with free and attach mark and finilizing functions
to= see if the problem disapears.

How to do such a test?

Any sug= gestion?

Regards
Stefan
--000e0cd5712c1da74c04affa64d4--