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=4.8 required=5.0 tests=DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id E3AE1BB84 for ; Thu, 30 Oct 2008 20:35:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAAypCUnRVZKwkGdsb2JhbACTTT4BAQEBCQkMBxEDrHR/ilYBAwEDg04 X-IronPort-AV: E=Sophos;i="4.33,517,1220220000"; d="scan'208";a="19400701" Received: from wa-out-1112.google.com ([209.85.146.176]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Oct 2008 20:35:44 +0100 Received: by wa-out-1112.google.com with SMTP id n4so387621wag.27 for ; Thu, 30 Oct 2008 12:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=cLnil8wmNrsCzR9H+a4dMrwlxIInBAzk9b7rt3Pvmik=; b=KAee5+eyMAG1tUWr1pRyIzPGT99zpN3X1KycQNgX53jZoTy82Eln1uotSD/QMrxA7d otsZqKNTv5lBL972FmyD9+K4txgdw2WhmmKEVzGwftC7fgREaeeDSqdBsLNYFcDJUgTB BQTZeGdTEVJK6EfwGM1rXWoObBH5V8TOeLTh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=a6IVD3WABhZg99hOv7E+4s/IEQrQ6NTRTbC9h+c/vLszMQuMp0jQIyARcZy2GBd1TX l5Ob/3YYXEY9SRgjOK6JoSyBd7fENf3+KHP0L839BteKpkKsCK1K8Yj5UqBGK9dn2Tro DLSMftBcUpDVPCknPpD4jiIxBhXtibGv0nPCk= Received: by 10.115.108.1 with SMTP id k1mr9031127wam.35.1225395342698; Thu, 30 Oct 2008 12:35:42 -0700 (PDT) Received: from timesink.corp.631h.metaweb.com (nat08.sjc1.metaweb.com [208.68.111.103]) by mx.google.com with ESMTPS id n30sm10094522wag.13.2008.10.30.12.35.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Oct 2008 12:35:41 -0700 (PDT) Cc: Message-Id: <8C745AFA-4FC2-4574-AB97-98321ECC4964@gmail.com> From: Warren Harris To: "CUOQ Pascal - Pascal.CUOQ@cea.fr" <+caml+warren+5dabfc3456.Pascal.CUOQ#cea.fr@spamgourmet.com> In-Reply-To: <5EFD4D7AC6265F4D9D3A849CEA9219191AB114@LAXA.intra.cea.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [Caml-list] RE: understanding weak Date: Thu, 30 Oct 2008 12:35:38 -0700 References: <20081030182019.EEBC5BBB7@yquem.inria.fr> <5EFD4D7AC6265F4D9D3A849CEA9219191AB114@LAXA.intra.cea.fr> X-Mailer: Apple Mail (2.929.2) X-Spam: no; 0.00; cuoq:01 cuoq:01 ocaml's:01 pointers:01 paper's:01 pointers:01 hash:01 hash:01 application-:01 warren:98 warren:98 renewal:98 wrote:01 wrote:01 caml-list:01 On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - Pascal.CUOQ@cea.fr wrote: > > Warren Harris wrote: >> I'd like to understand better how ocaml's weak pointers operate. > > You will be interested in the following important article: > http://portal.acm.org/citation.cfm?id=1411308 > :) Thank you for the reference. Looks like the paper's timing couldn't be better. > > >> First, although it doesn't seem to be specified in the documentation, >> I assume that weak pointers will *not* be reclaimed (e.g. from a weak >> hash table) if the program retains some other reference to the >> object. > > Exactly. > >> My second question relates specifically to my application. I would >> like to have a primary cache of objects, and a secondary index into >> sub-objects referenced from the primary cache. I.e. CacheA references >> objects of type A; objects of type A reference objects of type B; >> CacheB references objects of type B. I would like to guarantee that >> weak references in CacheB are not flushed unless the corresponding >> reference from CacheA is first flushed. I assume will be the case >> if a >> non-weak reference from A to B is maintained. > > The non-weak reference from A to B prevents B being unreachable > without A being unreachable, so yes, a reference from CacheB can > not disappear without the reference from CacheA disappearing > earlier or simultaneously. > This said, if what you want is really a cache, you would probably be > better off fixing its size and renewal strategy yourself than letting > the GC do it for you (by using weak pointers). What it will do has > almost > no chance of being the best compromise between memory use and > speed for your application, and it may change without notice from > one version to the other. In short: don't use weak pointers to make > caches. Thanks for the advice -- but I thought this was exactly what weak hash tables were intended for. (The paper seems to indicate that too.) I realize that an explicit replacement policy can be more application- friendly, but if what you really want is just "unless anyone is using this" then using weak hash tables would seem appropriate. > > >> Can anyone verify? > > If you want to experiment to confirm your impressions, the function > Gc.full_major is your friend. I'd hate to do an empirical analysis of this only to find I hadn't uncovered the full truth once the app was in production... so asking seemed like the way to go. Seems like the manual should say more here. Warren