Version française
Home     About     Download     Resources     Contact us    
Browse thread
mixing Ocaml with another GC-ed language
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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