> [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.

I'm willing to implement any of these 2 approaches, but it is not a
transparent change in either case.

- Xavier Leroy