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