From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA06156 for caml-redistribution; Thu, 20 Mar 1997 20:19:04 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA03085 for ; Thu, 20 Mar 1997 17:10:22 +0100 (MET) Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id RAA03619 for ; Thu, 20 Mar 1997 17:10:06 +0100 (MET) Received: from betze.bbn.hp.com by hplb.hpl.hp.com; Thu, 20 Mar 1997 16:10:01 GMT Received: from localhost (localhost [127.0.0.1]) by betze.bbn.hp.com with SMTP (8.7.1/8.7.1) id RAA02977; Thu, 20 Mar 1997 17:09:59 +0100 (MET) Message-Id: <199703201609.RAA02977@betze.bbn.hp.com> X-Authentication-Warning: betze.bbn.hp.com: Host localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: Emmanuel Engel Cc: caml-list@pauillac.inria.fr Subject: Re: Weak pointers In-Reply-To: Emmanuel.Engel's message of Thu, 20 Mar 1997 13:12:16 +0100. <333129A0.6CFA@lri.fr> X-Face: 7'_lwZ-\~X.Q]-O#D;ju@c|HTi9[>\U8jV5(8sQpm)twOCgN.y]9s:L}A1_]h}_LHF@U5!2 5~FJ"9)`@~BEg9d;ftlb:bj9N>RTv0[VvZe7EMMB:$9hUc]&d9VN? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 16:09:59 +0000 From: Kohler Markus Sender: weis > I wonder when Weaks pointers are erased by the GC. As soon > as it can be or when there is no more memory ? I can't speak for caml, but usally when there is no more memory, or the system is idle. > In the second > case, does all the weaks pointers that can be erased are erased > or just enough to allocate new memory. In this case, which are > erased, the older or the younger ? > > > Is it a good idea to use weak pointers to implement more > or less a cache ? IMHO not so a good idea. 1. Your replacement strategy for the cache will depend on internals of the garbage collector. 2. Also it almost always makes sense to have a cache with a limited size. Therefore you have to implement a replacement strategy anyway. On machines with virtual memory, the garbage collector ,may always "think" that there's more memory left and prefer to grow the process instead of reclaiming space. Garbage collection in virtual memory can be VERY slow. Markus -- +----------------------------------------------------------------------------+ | Markus Kohler Hewlett-Packard GmbH | | Software Engineer Network & System Management Division| | IT/E Success Team | +----------------------------------------------------------------------------+