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
Global roots causing performance problems
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-03-07 (16:45)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] Global roots causing performance problems
On Fri, Mar 07, 2008 at 03:10:05PM +0100, Xavier Leroy wrote:
> > [GC overhead of having many global memory roots]
> > We therefore wonder whether it wouldn't be much more effective to fix
> > the runtime.  I don't know the exact details of how things currently
> > work, but I guess that it would be possible to have two separate sets
> > of global roots for the minor and major heap.  Then, once a value gets
> > oldified, the global root, too, could wander to the corresponding set.
> >  The set for the major heap could then be scanned only once per full
> > major cycle, maybe even in slices, too.  Would this suggestion be easy
> > to implement?
> This "generational" approach is the natural solution to the problem
> you mention.  However, it is not compatible with the current API for
> global root registration: when a program registers a "value *" pointer
> using caml_register_global_root(), the program is free to change the
> value contained in that placeholder at any time without notifying the
> Caml memory manager.  As a consequence, the minor GC has no choice but
> scanning all global roots every time, because any of them could have
> been overwritten with a freshly-allocated Caml block since the
> previous minor GC.
> There are 2 ways to go about this problem:
> 1- Change the specs of caml_register_global_root() to prohibit
> in-place updates to the value contained in the registered value
> pointer.  If programmers need to do this, they must un-register the
> value pointer, update its contents, then re-register it.
> How much existing code would that break?  I don't know.
> 2- Keep the current API for backward compatibility and add a
> caml_register_global_immutable_root() function that would implement
> generational scanning of global roots, in exchange for the
> programmer's guarantee that the values contained in those roots are
> never changed.  Then, convince authors of Caml-C bindings to use the
> new API.

The second option is much preferable for two reasons:

(a) If libraries don't change then at least they don't break.

(b) It is possible to update a library by grepping through the source
for caml_register_global_root and then examining each call to see if
you can prove the new constraint.  If you can't be certain, well no
sweat, just leave it as it is.


Richard Jones
Red Hat