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=0.0 required=5.0 tests=none 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 E1E0ABC69; Fri, 7 Dec 2007 21:26:54 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOs6WUfUGypBkGdsb2JhbACBWo1+AgEBBwIIKQ X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="6597522" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Dec 2007 21:26:54 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lB7KQsP4019657 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK); Fri, 7 Dec 2007 21:26:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOs6WUfUGypBkGdsb2JhbACBWo1+AgEBBwIIKQ X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="6597521" Received: from smtp8-g19.free.fr ([212.27.42.65]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Dec 2007 21:26:53 +0100 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 74FE717F7D7; Fri, 7 Dec 2007 21:26:53 +0100 (CET) Received: from Macintosh-2.local (lns-bzn-53-82-65-52-144.adsl.proxad.net [82.65.52.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id F05D917F5B9; Fri, 7 Dec 2007 21:26:52 +0100 (CET) Message-ID: <4759AD8D.8020008@univ-savoie.fr> Date: Fri, 07 Dec 2007 21:31:09 +0100 From: Christophe Raffalli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-Christophe_Filli=E2tre?= Cc: Xavier Leroy , Thomas Fischbacher , 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 4759AC8E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 christophe:01 raffalli:01 univ-savoie:01 finalizers:01 footprints:01 filliatre:01 arrays:01 runtime:01 lri:01 filliatr:01 hash:01 hash:01 marshaling:01 Jean-Christophe Filliātre a écrit : > 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. > > Write size in C, marshaling is written with a hashtbl in C probably for that same reason ... Christophe