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=3.3 required=5.0 tests=DNS_FROM_SECURITYSAGE, SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 1B4D3BB84 for ; Fri, 31 Oct 2008 09:34:09 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYEAE9gCknAXQIngWdsb2JhbACUDgEBFiK4Y4NR X-IronPort-AV: E=Sophos;i="4.33,521,1220220000"; d="scan'208";a="30963749" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 31 Oct 2008 09:33:56 +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 m9V8XuPq025906 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 31 Oct 2008 09:33:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsBAF9fCklQW+UCe2dsb2JhbACUDgEBFiIEuE2DUQ X-IronPort-AV: E=Sophos;i="4.33,521,1220220000"; d="scan'208";a="18707135" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 31 Oct 2008 09:33:55 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KvpS2-0004dy-AE for caml-list@inria.fr; Fri, 31 Oct 2008 08:33:50 +0000 Received: from ip-210.net-89-3-222.rev.numericable.fr ([89.3.222.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Oct 2008 08:33:50 +0000 Received: from vanicat by ip-210.net-89-3-222.rev.numericable.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Oct 2008 08:33:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: vanicat@debian.org (=?utf-8?Q?R=C3=A9mi?= Vanicat) Subject: Re: understanding weak Date: Fri, 31 Oct 2008 09:33:38 +0100 Organization: none Message-ID: <87bpx1mae5.dlv@maison.homelinux.org> References: <20081030182019.EEBC5BBB7@yquem.inria.fr> <5EFD4D7AC6265F4D9D3A849CEA9219191AB114@LAXA.intra.cea.fr> <8C745AFA-4FC2-4574-AB97-98321ECC4964@gmail.com> <490A3DF9.5010700@frisch.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-210.net-89-3-222.rev.numericable.fr Mail-Copy-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:isOyFVNR6HczTJr8a/mtpGBgqhk= Sender: news X-Miltered: at concorde with ID 490AC2F4.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; frisch:01 frisch:01 cuoq:01 cuoq:01 pointers:01 hash:01 pointer:01 pointer:01 warren:98 garbage:01 wrote:01 wrote:01 cea:01 short:01 writes:01 Alain Frisch writes: > Warren Harris wrote: >> On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - Pascal.CUOQ@cea.fr wrote: >>> 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. > > Although there is some similarity between a weak table and a cache > ("store values, but feel free to get rid of them"), they are really > different beasts: a good implementation of a weak table should release > memory as soon as possible to avoid memory leak; a good implementation > of a cache should instead keep data as long as possible (until there > is a good reason to release it, like resource exhaustion). It's true, but it could be interesting to have a cache pointer/cache table provided with the garbage collector: it's the GC that know when there is not enough memory left, and that it should free those cache pointer to have some. -- Rémi Vanicat