> >     * OCaml GC but with all C allocations made directly into the old
> > generation (for conservativness)
>
> You still has to tell the (exact) minor collector about these
> allocations (ie something like putting them on the store list) - so
> you won't gain much in C coding style, and you'll lose in
> performance. The result of C primitives is usually a temporary value
> (e.g. because C primitives tend to be wrapped by Ocaml code doing
> checking and changing C errors into Ocaml exceptions), so you'll
> probably better put then in the young generation.

Since old generation collection is mostly conservative (compaction taken
appart) , allocating *by default* into the old generation and having a C
stack scanner could be a good compromise. The cases where the GC would not
be 'exact' is when the C code is calling back OCaml code, this might leave
several C values on the stack that might be mistaken with GC pointers.
Previous stack (before the interpreter loop) would not be scanned, neither C
globals so in most of the cases, no C stack would have to be scanned . That
leaves open the problem of distinction of C stacks vs OCaml stacks in native
mode... For performances issues, still using the CAML* macros and allocation
directly into the young generation would still be available.

> This interesting discussion triggers another interesting question:
> would Ocaml coders still use Ocaml if its implementation was (say) 3
> or 10 times slower than the current implementation? Alternatively, do
> people use my OcamlJitRun program which could provide (on several
> programs) a speedup of nearly 2 on their bytecode program (which don't
> have to be changed neither in their C primitives nor in the byteocde,
> hence the Ocaml source code).

The applications I'm writting are mainly speed critical (compilers,
generators), and deployed on box which does not have OCaml installed. Being
able to compile standalone native executables is a great thing and help a
lot for deployment.

Best Regards,
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