From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p5DCKn3a020554 for ; Mon, 13 Jun 2011 14:20:49 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAM//9U3U436rkWdsb2JhbABSEIQ5oW0UAQEBAQkLCwcUAyKIcq8mkA6BK4NvgQoEin2LBopZNw X-IronPort-AV: E=Sophos;i="4.65,358,1304287200"; d="scan'208";a="101172403" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Jun 2011 14:20:44 +0200 Received: from office1.lan.sumadev.de (dslb-094-219-214-193.pools.arcor-ip.net [94.219.214.193]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lapqe-1PqTra0sWG-00kQRu; Mon, 13 Jun 2011 14:20:38 +0200 Received: from [192.168.0.33] (dslb-084-058-008-075.pools.arcor-ip.net [84.58.8.75]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id CB5E15F701; Mon, 13 Jun 2011 14:20:37 +0200 (CEST) From: Gerd Stolpmann To: Yoonseok Ko Cc: caml-list@inria.fr In-Reply-To: <4DF55B5D.9090302@ropas.snu.ac.kr> References: <4DF55B5D.9090302@ropas.snu.ac.kr> Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Jun 2011 14:21:00 +0200 Message-ID: <1307967660.16462.49.camel@gps-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:s0f0tBMqkGuH0RCXe+u92clsu43Dh6Vh0UUIuqrV1LU HJtzKs6iOOB2t6PO+70A0lcQQMXawx/ddMhOFZRcH8SiDUCYqf 39iVmeX+U82aInc7OCOTRDnevdCpqyoloBe38p1Q0ByBFq0tpX rFY4WdjBKi+GLbNTDx+K7qDB0EiqXoVLDs0J/CZQuJXPLP0JNN lbJOBZeWeJA/kfybflmmQ== Subject: Re: [Caml-list] A question about GC. Am Montag, den 13.06.2011, 09:35 +0900 schrieb Yoonseok Ko: > Hello everyone. > I'm a graduate student majoring program analysis. > > I'm using Muddy which is BDD library interfacing Buddy. > The problem is that when I construct BDD, its memory blows up in some cases > because GC won't work. > (It was not only for Muddy problem. We already tried to use our own > buddy interface.) > > If I call Gc.compact () explicitly every cycle of constructing BDD, then > memory consumption is reasonable. > Gc.major () also works well, but Gc.minor () doesn't work. > I watched log messages of GC and figured out that they always try to > grow heap and very very rarely start new major GC cycle. > > In a small example, if I construct BDD only in non-tail-recursive form > function, memory blows up. > In a real code, tail-recursive form doesn't work. Just memory blows up. > So far, only the solution is just call Gc.major () explicitly. > > I'm using GC with default setting. > There was no memory leakage on buddy side. > I check the memory consumption both outside of the process and inside of GC. > > > I have two questions. > > 1. Is there any solution? Explicit garbage collection is too slow and > hard to collect garbage on time. > I want to know what happened in GC, and why GC won't work. Your problem sounds a bit like as if the custom blocks were allocated with the wrong parameters. Remember caml_alloc_custom has four parameters: caml_alloc_custom(ops, size, used, max) Often one sets here used=0 and max=1, but this may be totally wrong if you allocate larger blocks. Better set used=1, and max is the number of custom block allocations until the major GC is triggered. (Imagine there is a water level variable w, and for every allocation w:=w+used/max, and if w exceeds 1.0 the water tank is full, and another major GC is triggered.) Maybe this helps. Gerd > > 2. Sometimes GC log has this message: "Growing gray_vals to 32768k bytes." > What does that means? > > > Best Regards, > > Yoonseok Ko > >