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
How to write a GC for size > memory
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-11-13 (08:38)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] How to write a GC for size > memory
On Fri, Nov 13, 2009 at 06:10:03AM +0100, Goswin von Brederlow wrote:
> Normaly the GC would switch between defrag and freeing chunk
> mode. Both would be concurrent to normal filesystem
> operations. Possibly only run when the filesystem is idle. The
> compation mode would only happen in situations where the FS would
> otherwise have to return ENOSPC.
> To further improve this I would like to add a generational component
> into the GC. I have no mutables (except the roots) so an old chunk (or
> an old B-Tree node) can hold no references to a newer chunk. Also new
> files are far more likely to be deleted again than old files and new
> B-Tree nodes more likely to be modified again than old B-Tree
> nodes. Seems to screem for a generational approach. A generational
> approach should allow the GC to only scan a fraction of the B-Tree for
> its sweep. But I'm not quite sure how to go about that.
> Comments, Ideas, Improvements, Urls welcome.

As I said on IRC I still think ocaml-ancient is a good fit to this,
unless you are planning to modify the OCaml GC itself.

ocaml-ancient essentially converts parts of the heap to use manual
memory allocation, on top of which you can write a more suitable GC in
OCaml for your long-lived rarely-changing blocks (eg. one based on
reference counting).  The invariants you describe above are exactly
the ones which ocaml-ancient needs.


Richard Jones
Red Hat