Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sean Seefried <sean.seefried@n...>
Subject: Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
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