Browse thread
mixing Ocaml with another GC-ed language
[
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: | -- (:) |
| From: | Xavier Leroy <Xavier.Leroy@i...> |
| Subject: | Re: mixing Ocaml with another GC-ed language |
> It is not really plain C++ because I did code a (precise, mostly > copying, generational) garbage collector which is used in the > project. So Ocaml code will be called from (and will probably upcall > to) C++ code using my GC. So I do know my GC quite well (and studied > Ocaml's GC a bit also). My GC also support finalized objects, which it > does not move (so their address remain fixed). > > Does any people have concrete experience mixing Ocaml with another > GC-ed language (e.g. Java or Common Lisp) inside the same program? I can't say I have concrete experience, but I believe the following should work. So, we have two garbage-collected languages A and B, each managing its own heap. Assume both A and B support 1- finalized objects, and 2- explicit registration of GC roots. Then, to make an A object available to B, register the A pointer as a GC root for A (so that A doesn't reclaim it), allocate in B a proxy block containing the A pointer, and put a finalization function on the proxy block that un-registers the A pointer with A's GC when the proxy block is finalized. In this approach, A objects are viewed from B as an abstract type: B can't do anything with them except call A functions to operate on them. Allowing B to operate directly on A objects (e.g. read and write an array) is very language-dependent and generally hard; better go through foreign function calls. > I do have my precise ideas on the problem (essentially, avoid mixing > pointers from both worlds, either by copying data or by using my > finalized C++ GCed objects which are not moved by my GC). Copying is another option (that's what stubs generated by CamlIDL do, for instance). You get the benefit of having a concrete view on the data structure in both languages. But copying can be expensive on large structures, and also loses sharing for mutable objects. > The custom tag object (introduced in Ocaml3, see the Ocaml CVS > webserver) might also be helpful. Right. It's a generalization of OCaml's finalized objects, allowing you to attach to a Caml memory block not only a finalization function, but also an equality function, a hashing function, and serialization / deserialization functions (called by output_value and input_value). - Xavier Leroy