From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Gaylard Newsgroups: gmane.lisp.guile.devel Subject: Re: Memory accounting in libgc Date: Wed, 12 Mar 2014 10:27:37 +0200 Message-ID: <53201A79.1040704@computer.org> References: <87k3c33awa.fsf@pobox.com> <874n339a4z.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1394612871 12771 80.91.229.3 (12 Mar 2014 08:27:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2014 08:27:51 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 12 09:27:57 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WNeW4-0000gq-L4 for guile-devel@m.gmane.org; Wed, 12 Mar 2014 09:27:56 +0100 Original-Received: from localhost ([::1]:59294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNeW4-0007vv-90 for guile-devel@m.gmane.org; Wed, 12 Mar 2014 04:27:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNeVw-0007vp-R1 for guile-devel@gnu.org; Wed, 12 Mar 2014 04:27:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNeVr-00036p-6x for guile-devel@gnu.org; Wed, 12 Mar 2014 04:27:48 -0400 Original-Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:61046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNeVq-00036l-RN for guile-devel@gnu.org; Wed, 12 Mar 2014 04:27:43 -0400 Original-Received: by mail-wg0-f42.google.com with SMTP id y10so11062766wgg.13 for ; Wed, 12 Mar 2014 01:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7197uOaXtMLwvQCvEg4LF0n7WzNvzbQBae/s+zffbEY=; b=xpM3C7n0F6lhfqeKXihP4AtRicuft+Ym+HCZPeQ3vefR2eYUZgibGJQk1lzZidDQ6A 3UYtH1neXmSn9SDlTBvthXUvDVn1EartOKQEvEdCFMQLeyeRhN3rS8yPklteXHK/nSE5 MOlMzOMlBFHl+ZB27dSHhhN9b5H+k6/maxgEL/gRg7c4HElNnTp3swB2hGTcCpolQ7YU DtvykzDR5Rya4GFsW98iizockLd9bjyTF5O1T1DvhuDTQwqBnQd3xQzeKRvF8Oqg4Pcl GPVySp8y4d5nYu32rMsfQFVHrLA4gHPYlSjZYnUOQWI5BWoDDpv1d3uHYAJrrggfF18e c7og== X-Received: by 10.180.12.43 with SMTP id v11mr6484784wib.33.1394612861179; Wed, 12 Mar 2014 01:27:41 -0700 (PDT) Original-Received: from [10.0.0.3] (41-132-90-112.dsl.mweb.co.za. [41.132.90.112]) by mx.google.com with ESMTPSA id r3sm67799813wjw.0.2014.03.12.01.27.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 01:27:40 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: <874n339a4z.fsf@yeeloong.lan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22a 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:16963 Archived-At: On 03/12/14 08:57, Mark H Weaver wrote: > Andy Wingo writes: > >> How does this affect libgc? >> >> First of all, it gives an answer to the question of "how much memory >> does an object use" -- simply stop the world, mark the heap in two parts >> (the first time ignoring the object in question, the second time >> starting from the object), and subtract the live heap size of the former >> from the latter. Libgc could do this without too much problem, it seems >> to me, on objects of any kind. It would be a little extra code but it >> could be useful. Or not? Dunno. > This could be generalized to the far more useful question: "How much > memory does this set of objects use?", although that's a slippery > question that might better be formulated as "How much memory would be > freed if this set of objects were no longer needed?". > > For example, suppose you have a large data structure that is referenced > from two small header objects, A and B. If you ask "How much memory > does A use?", the answer will be the size of the small header, and ditto > for B. Without being able to ask the more general question, there's no > way to find out how much would be freed by releasing both. > > Mark Agreed. In order to build industrial-strength applications in guile, it's important to be able to answer questions such as "what is causing my process' memory usage to grow?" -- Andrew Gaylard