From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=NO_REAL_NAME,SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4B906BC69 for ; Fri, 7 Dec 2007 12:19:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEK7WEfAXQImh2dsb2JhbACOYXYCAQgKKQ X-IronPort-AV: E=Sophos;i="4.23,266,1194217200"; d="scan'208";a="6580386" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Dec 2007 12:19:01 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lB7BJ17f023800 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 7 Dec 2007 12:19:01 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALa6WEfVuiVnl2dsb2JhbACOYXYCAQEHBAYJCBEH X-IronPort-AV: E=Sophos;i="4.23,266,1194217200"; d="scan'208";a="5378418" Received: from 25.mail-out.ovh.net ([213.186.37.103]) by mail1-smtp-roc.national.inria.fr with SMTP; 07 Dec 2007 12:19:01 +0100 Received: (qmail 21241 invoked by uid 503); 7 Dec 2007 11:19:22 -0000 Received: (QMFILT: 1.0); 07 Dec 2007 11:19:22 -0000 Received: from b7.ovh.net (HELO mail237.ha.ovh.net) (213.186.33.57) by 25.mail-out.ovh.net with SMTP; 7 Dec 2007 11:19:22 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 7 Dec 2007 11:18:48 -0000 Received: from adret2.inrialpes.fr (adret2.inrialpes.fr [194.199.23.100]) by imp.ovh.net (IMP) with HTTP for ; Fri, 07 Dec 2007 12:18:48 +0100 Message-ID: <1197026328.47592c1859829@imp.ovh.net> Date: Fri, 07 Dec 2007 12:18:48 +0100 From: forum@x9c.fr To: caml-list@inria.fr Subject: Re: [Caml-list] Questions on replacing finalizers and memory footprints References: <4757D904.2090502@functionality.de> <475909E8.7010301@inria.fr> <4759241C.4070202@lri.fr> In-Reply-To: <4759241C.4070202@lri.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 194.199.23.100 X-Miltered: at discorde with ID 47592C25.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; finalizers:01 footprints:01 filliatre:01 filliatre:01 lri:01 arrays:01 runtime:01 lri:01 filliatr:01 hash:01 hash:01 wrote:01 terminate:01 caml-list:01 tuples:01 Selon Jean-Christophe Filliātre : > Xavier Leroy wrote: > >> Also, is there a simple way to implement a function (perhaps using > >> Obj.magic) which will walk a (possibly circular) network of tuples, > >> arrays, variadic entities and lists, and return the total number of > >> bytes used up by that structure? I see that this should be possible > >> in principle with the present implementation of the runtime if one > >> could get some basic information about the internal type of an > >> array. > > > > Jean-Christophe Filliātre's "size" library does exactly this: > > > > http://www.lri.fr/~filliatr/software.en.html > > Indeed. However, note that it uses internally a hash table to store > blocks already considered (in order to correctly account for sharing), > and thus it is potentially incorrect if the GC moves some blocks during > the count, for instance during a resizing of the hash table (which > triggers the GC). I don't know how to avoid this issue; any help is welcome. Sorry for the noise but doesn't this mean that the "size" function may not terminate ?