From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Memory accounting in libgc Date: Wed, 12 Mar 2014 02:57:48 -0400 Message-ID: <874n339a4z.fsf@yeeloong.lan> References: <87k3c33awa.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394607501 19311 80.91.229.3 (12 Mar 2014 06:58:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2014 06:58:21 +0000 (UTC) Cc: bdwgc@lists.opendylan.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 12 07:58:28 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 1WNd7T-0007TN-Ue for guile-devel@m.gmane.org; Wed, 12 Mar 2014 07:58:28 +0100 Original-Received: from localhost ([::1]:58993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd7T-0002UE-2M for guile-devel@m.gmane.org; Wed, 12 Mar 2014 02:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd7I-0002TF-W8 for guile-devel@gnu.org; Wed, 12 Mar 2014 02:58:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNd7C-0007pL-PD for guile-devel@gnu.org; Wed, 12 Mar 2014 02:58:16 -0400 Original-Received: from world.peace.net ([96.39.62.75]:45127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd7C-0007pE-LZ for guile-devel@gnu.org; Wed, 12 Mar 2014 02:58:10 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WNd73-00028h-Qt; Wed, 12 Mar 2014 02:58:02 -0400 In-Reply-To: <87k3c33awa.fsf@pobox.com> (Andy Wingo's message of "Sun, 09 Mar 2014 11:48:53 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:16962 Archived-At: 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