From: Sean Seefried <sean.seefried@nicta.com.au>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
Date: Sun, 13 Jul 2008 23:25:38 +1000 [thread overview]
Message-ID: <50710496-7007-4A9C-BFA4-DB98EEAD360E@nicta.com.au> (raw)
In-Reply-To: <20080712085016.GA430@annexia.org>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
After a weekend's worth of ruminating I have finally found the bug in
my code. It didn't turn out to be a root registration problem but your
pointer to this possible cause led me to read a lot of interesting
things about the garbage collector which, indirectly, helped me find
the problem.
Xavier, I ran into a problem with CamlIDL when translating C data
structures to OCaml ones. The problem was that I was translating a
really large data structure with a lot of sharing. Most structs had
next, prev, and parent pointers which meant that many, many recursive
calls were made. This eventually blew the stack.
So what I decided to do was create a hashtable. Whenever I
encountered a C pointer type I first allocated memory for the OCaml
value filled it's fields with dummy values and then associated the
address of the C structure (the key) with the address of the OCaml
value (the value). This was great because whenever I came across the
same C pointer again I would just look up the value and use that.
However, I failed to think about garbage collection!
Naturally, whenever garbage collection is done the OCaml values are
moved in memory, but the addresses of the OCaml data structures in my
hash table stay the same. This is no good since those very same
addresses become available again to be allocated by
camlidl_alloc_small. This can lead to all sorts of unpleasantness!
So now I have a question. Is there any way that I can find out what
address the garbage collector moves these values to? I need to update
the table when this happens.
Sean
[-- Attachment #2: Type: text/html, Size: 1936 bytes --]
next prev parent reply other threads:[~2008-07-13 13:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-12 6:07 Sean Seefried
2008-07-12 6:09 ` Sean Seefried
2008-07-12 8:50 ` Richard Jones
2008-07-13 13:25 ` Sean Seefried [this message]
2008-07-13 13:37 ` Gordon Henriksen
2008-07-13 14:03 ` Thomas Crimi
-- strict thread matches above, loose matches on Subject: below --
2008-07-11 8:21 Sean Seefried
2008-07-11 9:40 ` [Caml-list] " Richard Jones
2008-07-11 9:51 ` Richard Jones
2008-07-11 10:21 ` Sean Seefried
2008-07-11 15:56 ` Richard Jones
2008-07-11 14:11 ` Xavier Leroy
2008-07-12 3:20 ` Sean Seefried
2008-07-12 6:00 ` Sean Seefried
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=50710496-7007-4A9C-BFA4-DB98EEAD360E@nicta.com.au \
--to=sean.seefried@nicta.com.au \
--cc=Xavier.Leroy@inria.fr \
--cc=caml-list@inria.fr \
/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