Xavier Leroy a écrit :

Hello,

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

I'm using caml_register_global_root extensively in Aurochs when building
the parse tree, and updating it in-place (consing a list of children nodes,
actually.)

If you change the semantics of caml_register_global_root() it would
be nice to have a caml_modify_global_root() macro that does what is
needed.

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

That's the better solution IMHO, as it won't break existing code and gives
a clear migration path to better performance and improved customer satisfaction.

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

-- 
Berke DURAK