Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Basile Starynkevitch [local] <basile.starynkevitch@i...> |
| Subject: | Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml |
On Sun, Aug 29, 2004 at 12:12:05PM +0200, Nicolas Cannasse wrote: > > > * 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. [....] No, Ocaml's major GC (the garbage collection of the old generation) is not conservative; it is precise (it knows exactly where the pointers are), but is an incremental mark&sweep - with occasionnal call to the compactor whichs compacts the whole heap (including old stuff) by moving values & updating pointers. So I don't think Ocaml's GC could be easily patched to have the old GC work conservatively - hence avoiding the requirement of telling the runtime what are the pointers (ie CAMLlocal* & CAMLparam* macros). (I'm not sure that Nicolas Cannasse uses the "conservative" word in the established sense of the GC experts - perhaps my previous explanations where not clear enough). There is no way to conservatively scan the C stack, because the Ocaml GC may move pointers (and it has to, in order to be performant). (Damien Doligez would probably explain better than I could) Regards. -- Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr other email : basile at starynkevitch dot net Project cristal.inria.fr - temporarily http://cristal.inria.fr/~starynke --- all opinions are only mine ------------------- 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