From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p5DAbtn6017857 for ; Mon, 13 Jun 2011 12:37:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0CABro9U3RVdg2kGdsb2JhbAA8AQMSEKYiCBQBAQEBCQkNBxQEIawpjnqDY4keAQEDBoYeBIpthkeLXzyBMoFbNw X-IronPort-AV: E=Sophos;i="4.65,357,1304287200"; d="scan'208";a="85303299" Received: from mail-qw0-f54.google.com ([209.85.216.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Jun 2011 12:37:47 +0200 Received: by qwc9 with SMTP id 9so3615243qwc.27 for ; Mon, 13 Jun 2011 03:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VbS+1cRljzipRoRm9UvRWvHrbFUSR70th0LFlsU+LGc=; b=DoALDZdCLbaBSDaPuW/MPigdeIxxy54SZE9ahBJUWGWYEW2nGomX6CJiMf1GHEf+iO b90zXp4ZNaHJY1DHmOW59xRVCtVmD8TDqRNsH/PHuOy9ZYkdxcrR/+e/SAXLsSDD+YPb ivKhz/nc8xoUoRxDUy3IYiW7M+J61bM3xyUmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fsIH8Vceb0VSKn43o/16YGihhTdSIskFfHbjTHn8OF5FDg6SFSlxA2fXLBBkOTMJy2 0zaApcM3em5XliSCqBeXvmFXK7K6i8kb+YMcDx6wOR7h+/Fm0eITtSoPprPjdCEfRihh IylUARuhe7Kt0nqc0sUqK4KS9RLeu8kjW7HN8= MIME-Version: 1.0 Received: by 10.229.88.144 with SMTP id a16mr3621993qcm.45.1307961466521; Mon, 13 Jun 2011 03:37:46 -0700 (PDT) Sender: philippe.wang.lists@gmail.com Received: by 10.229.182.6 with HTTP; Mon, 13 Jun 2011 03:37:46 -0700 (PDT) In-Reply-To: <4DF55B5D.9090302@ropas.snu.ac.kr> References: <4DF55B5D.9090302@ropas.snu.ac.kr> Date: Mon, 13 Jun 2011 12:37:46 +0200 X-Google-Sender-Auth: xiQZ03b4mkwN2A0vZtltXU9OScA Message-ID: From: Philippe Wang To: Yoonseok Ko Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p5DAbtn6017857 Subject: Re: [Caml-list] A question about GC. As far as I know, when OCaml's GC is not working as expected, it's (almost) always because there are blocks allocated outside OCaml's heap (a.k.a. custom blocks). How big are custom blocks? The bigger they are, the worst the behavior tends to be. How much do you allocate in OCaml's heap (i.e., "normal OCaml values")? The more you allocate small values, the more efficient your program becomes (well, don't allocate way too much useless values either). For instance, what is your program's behavior if you replace Gc.compact() (or Gc.whatever_triggers_a_notTooMinor_collection...) by something like (Array.init 10000 string_of_int) ? -- Philippe Wang mail@philippewang.info On Mon, Jun 13, 2011 at 2:35 AM, Yoonseok Ko wrote: > 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. > > 2. Sometimes GC log has this message: "Growing gray_vals to 32768k bytes." >    What does that means? > > > Best Regards, > > Yoonseok Ko >