caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Yoonseok Ko <ysko@ropas.snu.ac.kr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] A question about GC.
Date: Mon, 13 Jun 2011 14:21:00 +0200	[thread overview]
Message-ID: <1307967660.16462.49.camel@gps-desktop> (raw)
In-Reply-To: <4DF55B5D.9090302@ropas.snu.ac.kr>

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
> 
> 



  parent reply	other threads:[~2011-06-13 12:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13  0:35 Yoonseok Ko
2011-06-13  9:40 ` Guillaume Yziquel
2011-06-13 10:37 ` Philippe Wang
2011-06-13 11:34   ` ygrek
2011-06-13 12:19     ` Guillaume Yziquel
2011-06-13 13:26       ` Philippe Wang
2011-06-13 12:21 ` Gerd Stolpmann [this message]
2011-06-13 12:26   ` Guillaume Yziquel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1307967660.16462.49.camel@gps-desktop \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=ysko@ropas.snu.ac.kr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).