Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-08-28 (17:02)
From: Nicolas Cannasse <warplayer@f...>
Subject: [Caml-list] (GC issues) Alternative Bytecodes for OCaml
> Unfortunately, Parrot
> implement all structured objects as PMCs, which are opaque data chunks
> on which all operations goes thru a table of functions (similar to C++
> vtables). So, using PMCs for tuple implementations would require an
> indirect call (even with Parrot JIT technology) for every basic tuple
> operations (ie allocation, tag fetching, field fetching). Also, I am
> not sure that Parrot has terminal (tail recursive) calls which are
> essential to Ocaml (and other functional languages).

That's the kind of things I was thinking when talking about object oriented
VM . In the OO world, everything is an object and people tends to abstract
everything - even fields, so pure efficient data structures are not
available anymore, only through expensive getter/setter and/or field lookup.
A functionnal VM typicaly need both : efficient direct access data
structures and objects with runtime lookup.

> Alos, note that Ocaml (and other functional languages) need a
> performant garbage collector (because immutable tuples and closures
> are allocated and accessed a lot), and that conservative GCs (à la
> Boehm) have lots of interesting features (in particular,
> conservativeness which makes then C-friendly, and multithreading), but
> are slower than naive generational copying precise GC (see
> for some benches).

I would like to get your thoughs about the following, since you already
wrote a GC as well as OCamlJIT.
IMHO, having an any way to interface with C is a key feature for any
language. Because the OCaml GC is not scanning the C stack, it is needed to
use a lot of macros to take care that newly allocated blocks are not

What would be the cost of extending the OCaml GC with a C stack scanning
pass ?
Would it be costly/unsafe to move the pointers on the C stack ?
What kind of speed factor can you loose when using for example Boehm GC in
OCaml VM instead of OCaml GC ?
Which would be better of theses two ?
    * a conservative GC everywhere (Boehm GC for example)
    * OCaml GC but with all C allocations made directly into the old
generation (for conservativness)

I'm also of course interested in Damien thoughts about theses questions.

Nicolas Cannasse

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: