From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q33CE3xk019009 for ; Tue, 3 Apr 2012 14:14:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0DALfoek+GnQCBlGdsb2JhbABFt3AiAQEBAQkLCQkUAySCCQEBBTo/EAsOCi4USS6Hbgu7M5ADYwSVYoESkgg X-IronPort-AV: E=Sophos;i="4.75,362,1330902000"; d="scan'208";a="152483252" Received: from shiva.jussieu.fr ([134.157.0.129]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2012 14:13:58 +0200 Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q33CDTcr015312 ; Tue, 3 Apr 2012 14:13:42 +0200 (CEST) X-Ids: 168 Received: from strontium.pps.jussieu.fr (strontium.pps.jussieu.fr [134.157.168.38]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 1D7CDC0172; Tue, 3 Apr 2012 14:13:28 +0200 (CEST) Received: from vouillon by strontium.pps.jussieu.fr with local (Exim 4.77) (envelope-from ) id 1SF2c3-0007c9-Tf; Tue, 03 Apr 2012 14:13:27 +0200 Date: Tue, 3 Apr 2012 14:13:27 +0200 From: Jerome Vouillon To: Gerd Stolpmann Cc: Hans Ole Rafaelsen , "Richard W.M. Jones" , caml-list@inria.fr Message-ID: <20120403121327.GA29159@pps.jussieu.fr> References: <20120401195733.GB15870@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Miltered: at jchkmail.jussieu.fr with ID 4F7AE969.007 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F7AE969.007/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Subject: Re: [Caml-list] Strategies for finding memory leaks On Tue, Apr 03, 2012 at 12:42:08PM +0200, Gerd Stolpmann wrote: > This reminds me of a problem I had with a specific C binding (for mysql), > years ago. That binding allocated custom blocks with badly chosen > parameters used/max (see the docs for caml_alloc_custom in > http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc144). If the > ratio used/max is > 0, these parameters accelerate the GC. If the custom > blocks are frequently allocated, this can have a dramatic effect, even for > quite small used/max ratios. The solution was to change the code, and to > set used=0 and max=1. > > This type of problem would match your observation that the GC works more > and more the longer the program runs, i.e. the more custom blocks have > been allocated. > > The problem basically also exists with bigarrays - with > used= and max=256M (hardcoded). I have also observed this with input-output channels (in_channel and out_channel), where used = 1 and max = 1000. A full major GC is performed every time a thousand files are opened, which can result on a significant overhead when you open lot of files and the heap is large. -- Jerome