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=2.1 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id B1995BB84 for ; Tue, 29 Jul 2008 15:39:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAANu5jkjRVYC6lGdsb2JhbACSFEMBAQEBCQMKBxEDmCOFQQ X-IronPort-AV: E=Sophos;i="4.31,272,1215381600"; d="scan'208";a="15556548" Received: from fk-out-0910.google.com ([209.85.128.185]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Jul 2008 15:39:31 +0200 Received: by fk-out-0910.google.com with SMTP id k31so5295307fkk.11 for ; Tue, 29 Jul 2008 06:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=/3NqptemKQQt4eAdxkGqIhKcgbPxtm2IDiMbj9PX6yY=; b=kWBXGbs+G+7SR0eH6Z3lAA+0wJ07izdDwd0Q7/07SScweQrqXVipcCHYpaQ6bLwu6X wsKNmp/TwPikuJZTg0zJ8bj5DceRux5d9jMmNtgxeDB0v1vT6kfO8xo8H4x9zRt5ccbP rmITr+5RpxsR4X2FIe41iBtHi95zeuOtxMQTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mTTXRayQedtXwPGS6SDwdPlKyPl7vvqgrPTWJRUfR8b20fuiDPb/4h02nktzeU7uRX +7pOoz/pTN+qgxXK+44BjVSt2mK+Arnu4llw7e2yfkq6LPExzz2OmTK4FONSu+8E3lIH ubUCX3HbZ7Cow7vZyCTwI4mMEpsYrx2oRkiso= Received: by 10.180.245.15 with SMTP id s15mr2084284bkh.103.1217338770799; Tue, 29 Jul 2008 06:39:30 -0700 (PDT) Received: by 10.180.233.8 with HTTP; Tue, 29 Jul 2008 06:39:30 -0700 (PDT) Message-ID: Date: Tue, 29 Jul 2008 09:39:30 -0400 From: "Jean Krivine" Sender: jean.krivine@gmail.com To: "Damien Doligez" , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Manually triggering garbage collection In-Reply-To: <08F66ABF-5C25-4D49-8B0B-77B2F757C1DD@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <08F66ABF-5C25-4D49-8B0B-77B2F757C1DD@inria.fr> X-Google-Sender-Auth: d00ae9b4d3364ab4 X-Spam: no; 0.00; krivine:01 krivine:01 damien:01 damien:01 ocaml:01 cvs:01 hms:98 26,:98 doligez:01 doligez:01 garbage:01 wrote:01 wrote:01 heap:01 caml-list:01 OK great I' ll try, For the moment I just set a Gc alarm that detects whether memory usage is above a certain limit and if so, sets the overhead to 0, which stops completely the memory "leak". Do you think that would improve to increase the size of the major heap? Also, do you know how often the alarm is tested? is it each time a major collection is performed? Thanks a lot J On Tue, Jul 29, 2008 at 8:53 AM, Damien Doligez wrote: > Hello Jean, > > On 2008-07-26, at 21:15, Jean Krivine wrote: > >> I am running a memory intensive stochastic simulator written in ocaml. >> After initialization of the data structure (which eats up a lot of >> memory but that's normal) I observe a memory leak during the >> simulation which should not be there. >> I noticed that if I run Gc.major() every n computation events after >> initialization (I can make n vary), then there is no more memory leak >> (the memory the process is using is constant). >> >> So my question is the following: >> Is there a rational way to detect I should call for Gc.Major()? (for >> the moment I am triggering it every n events which is arbitrary) > > > This might be a fragmentation problem, but if calling Gc.major() > fixes it, I guess it's not a true leak (i.e. the memory would stabilize > at some point). > > At any rate, you might want to try the CVS head version (3.11+dev): > it uses first-fit allocation in order to fight fragmentation, and I'd > like to know how well it does in the wild. > > -- Damien > >