Browse thread
Regarding SMP computing
[
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: | Markus Mottl <markus.mottl@g...> |
| Subject: | Re: [Caml-list] Regarding SMP computing |
On 9/26/06, Damien Doligez <damien.doligez@inria.fr> wrote: > The GC doesn't work by checking whether something has become > unreachable. It works by marking all reachable data, then deallocating > everything else. There is no way to do what you want in OCaml, and > I don't think it can be done without a major rework of the runtime > system. But isn't it true that the GC doesn't follow pointers that point outside the OCaml-heap? In that case it might be conceivable to copy OCaml-data that must not be reclaimed into the C-heap. Of course, this would mean that pointers must not point back into the OCaml-heap from there, because there is no way the GC could know then that some value in the OCaml-heap is still in use, or how to update the pointer in the C-heap in case the OCaml-value gets moved around, e.g. during a compaction. If the above really works, I'd be glad to know whether there is already functionality to copy OCaml-structures around. We have some applications that would greatly benefit from this feature, too: they require an enormous amount of static background knowledge, and have to use it for small jobs which can be easily distributed. We have multi-core, multi-processor machines, and would be able to greatly speed up our compute jobs if we could put these large OCaml-values into a shared-memory region. It would save us both a hell lot of memory (probably in the range of GBs per machine for some jobs), and also make the GC work less hard marking data that is not going to be reclaimed anyway. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com