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=1.1 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 636D8BC69 for ; Fri, 7 Dec 2007 21:58:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKZCWUfAXQImh2dsb2JhbACPWAIBCAopgRQ X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="5009144" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 07 Dec 2007 21:58:41 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lB7KwehQ013303 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 7 Dec 2007 21:58:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKZCWUfV+70qnmdsb2JhbACPWAIBAQcEBimBFA X-IronPort-AV: E=Sophos;i="4.23,268,1194217200"; d="scan'208";a="20102785" Received: from 42.mail-out.ovh.net ([213.251.189.42]) by mail4-smtp-sop.national.inria.fr with SMTP; 07 Dec 2007 21:58:40 +0100 Received: (qmail 14436 invoked by uid 503); 7 Dec 2007 20:58:45 -0000 Received: from gw2.ovh.net (HELO mail246.ha.ovh.net) (213.251.189.202) by 42.mail-out.ovh.net with SMTP; 7 Dec 2007 20:58:45 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 7 Dec 2007 20:58:17 -0000 Received: from mut38-5-82-246-191-110.fbx.proxad.net (HELO ?82.246.191.110?) (forum%x9c.fr@82.246.191.110) by ns0.ovh.net with SMTP; 7 Dec 2007 20:58:16 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <4759A501.7070809@lri.fr> References: <4757D904.2090502@functionality.de> <475909E8.7010301@inria.fr> <4759241C.4070202@lri.fr> <1197026328.47592c1859829@imp.ovh.net> <4759A501.7070809@lri.fr> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <75D66E7E-2C71-40E3-8F94-129821A06FFA@x9c.fr> Content-Transfer-Encoding: quoted-printable From: "forum@x9c.fr" Subject: Re: [Caml-list] Questions on replacing finalizers and memory footprints Date: Fri, 7 Dec 2007 22:01:23 +0100 To: caml-list@inria.fr X-Mailer: Apple Mail (2.752.2) X-Ovh-Remote: 82.246.191.110 (mut38-5-82-246-191-110.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Miltered: at discorde with ID 4759B400.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; finalizers:01 footprints:01 filliatre:01 hash:01 hash:01 hashtable:01 garbage:01 terminate:01 terminate:01 caml-list:01 termination:01 cyclic:01 data:02 size:95 size:95 Le 7 d=E9c. 07 =E0 20:54, Jean-Christophe Filli=E2tre a =E9crit : > forum@x9c.fr a =E9crit : >>> Indeed. However, note that it uses internally a hash table to store >>> blocks already considered (in order to correctly account for =20 >>> sharing), >>> and thus it is potentially incorrect if the GC moves some blocks =20 >>> 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 =20 >>> is welcome. >> >> Sorry for the noise but doesn't this mean that the "size" function =20= >> may not >> terminate ? > > No, simply that it may count a same block several times, because it =20= > 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. My mistake, I did not take into account the fact that if a block is =20 moved by the garbage collector, its reference is updated in the hashtable *too*. Hence the termination guarantee.