English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Regarding SMP computing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-09-26 (14:37)
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

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.


Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com