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 CBDD8BC69 for ; Fri, 7 Dec 2007 20:54:47 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPYzWUfAXQInh2dsb2JhbACPWAIBCAop X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="6596559" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Dec 2007 20:54:47 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lB7Jsk1w018731 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 7 Dec 2007 20:54:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGwzWUeBrw8Ek2dsb2JhbACPWAIBAQcEBgkg X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="20101282" Received: from ext.lri.fr ([129.175.15.4]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Dec 2007 20:54:46 +0100 Received: from localhost (localhost [127.0.0.1]) by ext.lri.fr (Postfix) with ESMTP id B0E19A48AD; Fri, 7 Dec 2007 20:54:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at lri.fr Received: from ext.lri.fr ([127.0.0.1]) by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id turtXafZCA1U; Fri, 7 Dec 2007 20:54:46 +0100 (CET) Received: from [192.168.0.10] (mry91-1-82-229-156-20.fbx.proxad.net [82.229.156.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ext.lri.fr (Postfix) with ESMTP id 690EEA48AB; Fri, 7 Dec 2007 20:54:46 +0100 (CET) Message-ID: <4759A501.7070809@lri.fr> Date: Fri, 07 Dec 2007 20:54:41 +0100 From: =?ISO-8859-1?Q?Jean-Christophe_Filli=E2tre?= User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: forum@x9c.fr Cc: 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> <1197026328.47592c1859829@imp.ovh.net> In-Reply-To: <1197026328.47592c1859829@imp.ovh.net> X-Enigmail-Version: 0.94.2.0 OpenPGP: url=http://www.lri.fr/~filliatr/mykey.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 4759A507.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; filliatre:01 filliatre:01 lri:01 finalizers:01 footprints:01 hash:01 hash:01 segfaults:01 bug:01 lri:01 filliatr:01 terminate:01 terminate:01 caml-list:01 cyclic:01 forum@x9c.fr a écrit : >> 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 ? No, simply that it may count a same block several times, because it was moved by the GC during a resizing of the hash table, between the first time it was seen and the next time it is reached from another block. So you may only overestimate the size of the data. It should not fail, and should terminate, even on cyclic values. Jon is reporting segfaults, though, so there must be a bug somewhere in my code (which uses Obj for obvious reasons). I'll have a look at it if Jon is able to send some faulty application. -- Jean-Christophe Filliâtre http://www.lri.fr/~filliatr/