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 p5D9gokl016084 for ; Mon, 13 Jun 2011 11:42:50 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMDAPXa9U3DumTngWdsb2JhbABSEKZAAQEWJiWIcr8iDoYWBJYDilk3 X-IronPort-AV: E=Sophos;i="4.65,357,1304287200"; d="scan'208";a="96661492" Received: from nwas13.bluewin.ch (HELO zhbdzmsp-nwas13.bluewin.ch) ([195.186.100.231]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Jun 2011 11:42:45 +0200 Received: from [83.76.55.36] ([83.76.55.36:62624] helo=seldon) by zhbdzmsp-nwas13.bluewin.ch (envelope-from ) (ecelerity 2.2.2.45 r()) with ESMTP id CF/D9-01173-A8BD5FD4; Mon, 13 Jun 2011 09:42:45 +0000 Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1QW3dY-0005oj-C2; Mon, 13 Jun 2011 11:40:48 +0200 Date: Mon, 13 Jun 2011 11:40:48 +0200 From: Guillaume Yziquel To: Yoonseok Ko Cc: caml-list@inria.fr Message-ID: <20110613094048.GE6158@localhost> References: <4DF55B5D.9090302@ropas.snu.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DF55B5D.9090302@ropas.snu.ac.kr> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] A question about GC. Le Monday 13 Jun 2011 à 09:35:41 (+0900), Yoonseok Ko a écrit : > Hello everyone. > > 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. First you'll have to know what kind of values accumulate in the heap. If they are custom blocks, then you'll have a pointer in the block pointing to a structure that identifies the kind of values (as a general rule). If it's a problem in the binding, then looking closely at custom blocks is likely a good idea. Do not know about muddy, but it may be a good idea to tweak parameters in alloc_custom in order to force garbage collection often. If the problem goes away, I'd recommend reading closely about alloc_custom, look at how it is implemented, and modify muddy.c accordingly. Anyhow, for such GC problems, I'd recommend using ocamlviz. > 2. Sometimes GC log has this message: "Growing gray_vals to 32768k bytes." > What does that means? Good read on the topic: http://caml.inria.fr/pub/docs/oreilly-book/pdf/chap9.pdf In the marking phase of Mark & Sweep, gray cells are marked cells whose descendents are not yet marked. > Best Regards, > > Yoonseok Ko -- Guillaume Yziquel