Browse thread
Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
-
Sean Seefried
- Sean Seefried
-
Richard Jones
-
Sean Seefried
- Gordon Henriksen
- Thomas Crimi
-
Sean Seefried
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2008-07-13 (14:03) |
From: | Thomas Crimi <tcrimi@g...> |
Subject: | Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces |
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