Browse thread
Global roots causing performance problems
-
Markus Mottl
-
Xavier Leroy
- Berke Durak
- Richard Jones
- Markus Mottl
-
Xavier Leroy
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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. Rich. -- Richard Jones Red Hat