You could use Boehm's garbage-collector for such a project, indeed, that's what is done in Bigloo, to compile Scheme programs to C. Since Boehm's GC is conservative, it would probably work well in such a system, with or without compiler optimizations, but the GC itself would probably be much slower than OCaml's GC on monothreaded code. On the contrary, OCaml's GC is not conservative, so it really needs to know what is a pointer to OCaml data, and also to be warned when pointers to OCaml data are erased (what caml_modify does). If you leave the C compiler perform all its optimizations, you might end up with pointers to OCaml data that are not where they should be (typically, it can duplicate a variable to parallelize some computations when there are no dependencies between them, and the GC will only scan one of them). So, you have to limit the C compiler to only "safe" optimizations from that point of view. By the way, there are almost no optimizations performed in the Ocaml compiler on bytecode, most of the interesting ones are only performed in the native compiler. I think the philosophy behind this choice is that you want to compile very fast to bytecode (so, no time for optimization), and only use the native code compiler at the end for efficient code.
--Fabrice On Thu, Sep 16, 2010 at 12:46 PM, Eray Ozkural <examach...@gmail.com> wrote: > Yes, I've seen how wired the GC is in the ocaml sources. I had used the > Boehm GC in a compiler project (not for the generated code but the > compiler), > do you mean that one would have to disable most optimizations in the ocaml > bytecode > compiler to make such a hypothetical bytecode-to-C compiler work with a C > GC, or am I missing something crucial? It's great to be able to learn from > actual > ocaml compiler writers, BTW, your comments are much appreciated. > Regards, > On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant > <fabrice.le_fess...@inria.fr> wrote: >> >> The problem is still the same: even if the code is compiled by a C >> compiler, there is still the need for the garbage collector. If you >> don't provide your own conservative GC (for which you would have to >> reimplement all the native functions of OCaml), then you need to use >> OCaml GC, and you would have to disable most optimizations to be sure >> that the GC knows where to find live references. At the end, you would >> get almost no performance improvement, compared to just appending the >> assembly code for each bytecode instruction (see Piumarta's work in >> PLDI'98). >> >> --Fabrice >> >> Eray Ozkural wrote, On 09/16/2010 02:38 AM: >> > Well, what I would do is to apply a fully optimizing compiler from a >> > proper hardware abstraction layer, whether it is JIT is irrelevant, but >> > I do not see why the system would not start doing this as soon as the >> > code is loaded in some place (and not when it starts to run). What is >> > certain is that some simple transformation will not speed things up >> > much. >> _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
