From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 1B974BC57 for ; Wed, 1 Sep 2010 17:24:22 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.56,304,1280700000"; d="scan'208";a="66521100" Received: from macadam.inria.fr ([128.93.8.130]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 01 Sep 2010 17:24:22 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] More re GC hanging From: Damien Doligez In-Reply-To: Date: Wed, 1 Sep 2010 17:24:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1281855821.2115.4.camel@glinka> <1281863810.2115.11.camel@glinka> To: caml-list caml-list X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; damien:01 damien:01 iirc:01 memoized:01 basile:01 bindings:01 bindings:01 'print:01 endline:01 pointer:01 doligez:01 doligez:01 garbage:01 garbage:01 wrote:01 On 2010-08-15, at 12:45, Adrien wrote: > First, remove all non-tail-rec functions: no more List.map, @ or > List.concat. All lists were pretty short (definitely less than 1000 > elements) but maybe the amount of calls generated garbage or something > like that: I couldn't get much infos about the problem so I tried what > I could think of and being tail-rec couldn't be a bad thing anyway. > The idea was to create less values since I first suspected a memory > fragmentation issue (iirc I had thousands of fragments), so I also > memoized some functions. That has nothing to do with the GC getting huge counts. Also, if you have fragmentation problems, you can try changing the allocation policy with this statement: Gc.set {(Gc.get ()) with Gc.allocation_policy = 1};; I'm still waiting for feedback on that alternate allocation policy :-) > Then, as Basile mentionned, call something like Gc.compact () > regularly. The overhead is actually pretty small, especially if ran > regularly. That's good for tracking down problems, but I wouldn't recommend it for production code. > Finally, C bindings. I created a few while not having access to the > internet and they are quite dirty. I highly doubt they play perfectly > well with the garbage collector: they seem ok but probably aren't > perfect. That's definitely something to check, even if the bindings > were written by someone else because working nicely with the GC can be > quite hard. > > Now, the problem seems to be gone but I can't say for sure. One really > annoying thing was that adding a line like 'print_endline "pouet";' > would make the out-of-memory problem go away! Same when getting stats > from the GC. That almost certainly indicates a problem with your C bindings: some pointer gets garbled and the GC may or may not stumble upon it. -- Damien