Re: [Caml-list] Global roots causing performance problems

[Richard Jones <rich@annexia.org>]

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.

Rich.

-- 
Richard Jones
Red Hat