On Sun, 2005-06-26 at 17:31 +0200, Ralf Stephan wrote:
Why not pipe the C++ allocations into the GC as well as doing a search and replace of the remaining malloc()'s? This way everything lives in libgc and can be checked from there too.
Mainly because of bad interactions with libraries. They'll still be using malloc(), after all, and we'd have to add extra code to make sure that the garbage collector didn't prematurely collect objects while a malloc()ed object from some library (notably GTK) still held references to it. It would be very, very difficult to get right.
(What we do right now is have a reference-counted "shim" (Inkscape::GC::Anchored) which can be used to deal with references from non-GC-aware objects. But that's easy to deal with when we control those objects. Less so when those objects belong to other libraries...)
An alternative would be to use libgc in malloc-replacement mode, so everybody uses it. No code changes necessary (theoretically...). One problem -- libraries like gdk use malloc() to allocate large RGBA bitmaps. RGBA pixels are statistically likely to look like valid pointers (when you have a lot of them of various colors).
It'd be nice if there were some way to force gdk to use GC_malloc_atomic() for those bitmaps [to indicate to the collector that it's not supposed to scan for pointers there], but since there isn't, it'd basically just render the garbage collector useless.
(Actually in malloc-replacement mode we'd also have to disable GC::Anchored, or we'd have problems with reference cycles)
We do plan on increasing the amount of code that uses the collector, but experiences so far have shown that there are enough subtle issues involved that a simple search-and-replace isn't safe.
-mental