From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16043; Mon, 27 May 2002 10:19:14 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 KAA16174 for ; Mon, 27 May 2002 10:19:13 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4R8JDf08617; Mon, 27 May 2002 10:19:13 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16152; Mon, 27 May 2002 10:19:12 +0200 (MET DST) Date: Mon, 27 May 2002 10:19:12 +0200 From: Xavier Leroy To: francois bereux Cc: caml-list@inria.fr Subject: Re: [Caml-list] Garbage collector and memory fragmentation Message-ID: <20020527101912.C15615@pauillac.inria.fr> References: <3CEDEA7C.D2C9B8D6@fr.thalesgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3CEDEA7C.D2C9B8D6@fr.thalesgroup.com>; from francois.bereux@fr.thalesgroup.com on Fri, May 24, 2002 at 09:23:40AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > collection.> > > I have a program (in Fortran90) that uses many (> 100.000) small lists > of integers ( about 100 elements per list ). Each list is built > incrementally => I allocate many small blocks. It appears that this > leads to memory fragmentation. For instance, even though I deallocate > all the lists, the memory used by the program does not seem to really > decrease. > My question is : does a garbage collector (for instance the one in > OCaml) deal with this kind of issues ( defragmentation of the memory ) > in a situation similar to mine : many small lists of elements ? It depends on the allocation and garbage collection algorithms used. For instance, relocating garbage collectors (stop© collectors, or in-place compactors) prevent fragmentation, while garbage collectors that do not move objects around (mark&sweep, reference count) are vulnerable to fragmentation issues. Even for non-relocating collectors, the allocation strategy also has an impact on how much fragmentation occurs. To learn more, I'd recommend Paul Wilson's excellent surveys: ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps (on GC) ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps (on allocation) - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners