Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces

[Thomas Crimi <tcrimi@gmail.com>]

On Jul 13, 2008, at 9:25 AM, Sean Seefried wrote:

>
> 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.

  You have to register each of your pointers as global roots, but  
beware that doing so for a large number of objects can dramatically  
slow down the GC since all the roots must be scanned on each minor  
collection.  The main issue here is that the OCaml run-time can't tell  
if you're modifying root pointers behind its back;  pointing into the  
young generation, so each scan of the young generation needs to first  
check all root pointers.  It should be possible to better optimize  
this by having the C code promise not to do this without telling the  
GC, but such functions currently don't exist.

  A solution I've used in the past (surely obtained from this list) is  
to keep the Hashtable in OCaml, and register some functions that the C  
code can use to access it.  The C code can refer to objects long-term  
by integer ID which can be used for fast lookups.

  When you need the object, look it up by integer id to get the  
pointer.  Then, of course, register the pointer as a global root.   
Once your done with the object pointer you release the global root  
again (or just keep a single always-registered global root around and  
re-point it to each object you need).

   This keeps the number of global roots to a minimum but still allows  
fast access to the pointers.

   Generally in my code I've created C++ wrapper classes to wrap a  
'val' and provide C++-object-like access.  It's very easy to have a  
base class that properly manages root allocation / release and then  
never have to think about it again.  GC errors like this are insidious  
since your program can run for weeks without issue then one particular  
data-set causes a GC at the inopportune time and you have a mysterious  
crash.

   I'm not familiar with CamlIDL, so I'm not sure how amenable these  
tricks are.

  Regards,
   Tom