From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p5D0a3pL024908 for ; Mon, 13 Jun 2011 02:36:04 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcHANJa9U2TLtdJ/2dsb2JhbABShEmTTY43d6hJjkaPVYErg2+BCgSHC4ophE+LHQ X-IronPort-AV: E=Sophos;i="4.65,356,1304287200"; d="scan'208";a="96645526" Received: from ropas.snu.ac.kr ([147.46.215.73]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Jun 2011 02:35:50 +0200 Received: from [127.0.0.1] (let.snu.ac.kr [147.46.242.53]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ropas.snu.ac.kr (Postfix) with ESMTP id C2DEDEAA33 for ; Mon, 13 Jun 2011 09:35:46 +0900 (KST) Message-ID: <4DF55B5D.9090302@ropas.snu.ac.kr> Date: Mon, 13 Jun 2011 09:35:41 +0900 From: Yoonseok Ko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ko; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Caml-list] A question about GC. 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