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 AAA20236; Wed, 17 Apr 2002 00:41:59 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA17041 for ; Wed, 17 Apr 2002 00:41:58 +0200 (MET DST) Received: from sls.lcs.mit.edu (sls.lcs.mit.edu [18.27.0.167]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g3GMfv524906 for ; Wed, 17 Apr 2002 00:41:58 +0200 (MET DST) Received: from BEARWITHME (27-1-23.dynamic.lcs.mit.edu [18.27.1.23]) by sls.lcs.mit.edu (8.9.3/8.9.3) with SMTP id SAA23283; Tue, 16 Apr 2002 18:41:48 -0400 (EDT) Message-ID: <001e01c1e597$e2ca84b0$17011b12@BEARWITHME> From: "Scott Cyphers" To: "Brian Rogoff" , "Martin Jambon" Cc: References: Subject: Re: [Caml-list] Memory leak Date: Tue, 16 Apr 2002 18:41:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Sure. There was a great demo of this on the translator's list for the > O'Reilly book; create a representation of stacks based on arrays with a > top of stack index. Popping items off of the stack by moving the TOS > pointer around won't free them. Could you be doing something like that? In that particular case, the stack implementation is a lot uglier when you need to provide the ability to neutralize array elements of arbitrary type as you pop the stack. Sometimes you get lulled into thinking the GC works completely invisibly. Lisp Machines had special versions of GC that would first run through a list of GC user-definable initializers that would clear off history lists and other places that tended to accumulate garbage. With each new release, new garbage gatherers and problems like the stack implementation above needed to be tracked down and adjusted or added to the list. You get so you notice that kind of code and automatically unhook pointers when you're done with them. I think I caused the biggest leak when I added a compiler optimizer that removed reads for values that were never used. One part of this special garbage collection process played some GC space games and required a memory read to start the garbage collector, so we had to introduce read for effect. ------------------- 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