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 BAA05536; Fri, 25 Apr 2003 01:27:12 +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 BAA05495 for ; Fri, 25 Apr 2003 01:27:10 +0200 (MET DST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h3ONR9H26881 for ; Fri, 25 Apr 2003 01:27:09 +0200 (MET DST) Received: (qmail 24650 invoked from network); 24 Apr 2003 23:27:08 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 24 Apr 2003 23:27:08 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030424161059.03871008@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Apr 2003 16:21:46 -0700 To: Xavier Leroy From: Chris Hecker Subject: Re: [Caml-list] Str memory leak in 3.06? Cc: caml-list@inria.fr In-Reply-To: <20030424150955.C5587@pauillac.inria.fr> References: <4.3.2.7.2.20030424001900.037a2958@localhost> <4.3.2.7.2.20030424001900.037a2958@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 caml-list:01 3.06:01 regexps:01 alloc:01 parms:01 regexp:01 chris:01 caml:01 garbage:01 collector:02 objects:02 explicit:03 heap:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >No, there is no need for explicit deallocation of regexps. Actually, >there is no leak either: if you put a call to Gc.major() in the loop, >memory usage remains constant. Ah, I thought a Gc.compact () did a major collection (the docs say it does), and that didn't help. Maybe I didn't wait long enough? I just put the Gc.major () in there and waited a long time and it seemed to settle out eventually, but only after it had allocated 800MB and had paged the rest of the world out, which seems big. Shouldn't the major collection find that there is only one live regexp and collect all of the others, and keep the heap way smaller than 800MB? >What happens is that the speed of the (incremental) major collector >isn't appropriately adjusted, so it runs too slowly and lets "floating >garbage" accumulate. This is a common problem with Caml objects that >are just handle on resources allocated outside the Caml heap: precise >determination of the space consumption of the latter is generally >impossible, causing the incremental major GC to run often too slowly, >sometimes too fast... Ah, is there something Str could do to avoid this, like setting the mysterious alloc_custom parms differently? Also, how could I have figured this out myself and not bothered the list? Thanks, Chris ------------------- 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