Re: mixing Ocaml with another GC-ed language

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Tue Feb 29 2000 - 11:24:06 MET

  • Next message: Jean-Christophe Filliatre: "wish: hash function for module Num"

    > 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



    This archive was generated by hypermail 2b29 : Wed Mar 01 2000 - 17:33:33 MET