caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Philippe Wang <mail@philippewang.info>
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 12:37:46 +0200	[thread overview]
Message-ID: <BANLkTi=CS2yj+XC6KZMMsBh4mhX+gS1uJg@mail.gmail.com> (raw)
In-Reply-To: <4DF55B5D.9090302@ropas.snu.ac.kr>

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 <ysko@ropas.snu.ac.kr> 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
>


  parent reply	other threads:[~2011-06-13 10:37 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 [this message]
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
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='BANLkTi=CS2yj+XC6KZMMsBh4mhX+gS1uJg@mail.gmail.com' \
    --to=mail@philippewang.info \
    --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).