> Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html
> 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
> http://starynkevitch.net/Basile/qishintro.html 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
garbaged.

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 caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners