caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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 --]

  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;
as well as URLs for NNTP newsgroup(s).