On Tue, Apr 09, 2002 at 03:32:32PM +0100, [EMAIL PROTECTED] wrote: <snip> > Here are two mails from Havoc about the GC version of gtk. <snip> > Re: garbage collection experiment > > * From: Havoc Pennington <hp redhat com> > * To: gtk-devel-list gnome org > * Subject: Re: garbage collection experiment > * Date: 11 Feb 2001 15:30:55 -0500 > > Hi, > > Observations after further testing and discussion with Owen: > > - seems to work great with gtk-demo, even if I add a "malloc bomb" > idle function that uses 100% CPU constantly leaking memory; memory > usage of the process doesn't go up more than the non-GC case. > > - --enable-gc-friendly may help a lot with GC, if people were going > to use a thing like libggc as an application add-on with any > frequency, GLib should probably default to gc-friendly since apps > can't depend on specific glib build options. --disable-mem-pools > can also be a good idea in a GC environment, but potentially more > costly in the non-GC environment. > > - At the moment, refcounted objects don't get collected > until refcount == 0 because someone still has a pointer to the > object in order to call unref(). If you actually want to take > advantage of GC, of course you wouldn't keep that pointer, > so stuff would get collected with refcount > 0; this means in > essence that finalizers don't get called, so in any case that > a finalizer does more than call free()/unref() on sub-objects, > things will break. > > Anyhow, doing more than free/unref in a finalizer is conceptually > broken even now, but broken in practice with a collector most > likely, since finalizers will just get skipped. > > Boehm has hooks to register a finalizer for a block, but these > can't really be used for GObject; one issue is that it can't > collect cycles involving finalized objects, because normally if A > points to B, it finalizes A then B, but if A and B are in a cycle, > there's no safe finalization order. Another issue is that > finalizers slow stuff down and add overhead. Finally most objects > won't expect to be inside g_malloc() when finalized, which is where > the collector will do the finalization. how an anyone assume to have an specific finalization order ?! btw: in the case of cycles refcounting fails and leaves trash.
> It might be possible to have a Boehm-registered finalizer that > simply adds an object to a list of objects, then you call > GObject-level finalizers in some kind of idle handler, which keeps > finalizers from being called from inside a g_malloc() and avoids > some reentrancy problems; but, there are other issues that arise > with that. finalizers can be run in an separate thread. > Basically to make GC useful with refcounted objects, finalizers why using refcount when you have an garbage collector ? <snip> > - I can't get the incremental GC feature of the Boehm collector to > make any difference; it always does full collections anyway for > some reason. I guess it's good the full collector is fast enough, > the incremental collector has some weird issues (it has to > be able to detect the dirty bit on pages, done by various > platform-specific hacks that don't always work) this stuff should be thought as an additional optimization which is hidden behind the normal full collector. > - There are certainly portability issues with the Boehm collector, in > particular right now it just punts on shared libraries and only > builds a static lib, and I'm using an unportable hack to get it > into a shared lib. The gcj team has it autotoolized and Tom says > Boehm may merge that upstream sometime. Of course the collector > implementation itself is a huge nest of platform dependent hacks, > unavoidably, but it's ported to most platforms. ... implementation details ... > The only real showstopper I see for using this in real apps is the > issue of finalizers. You could use it for real apps now if you do > manual refcounting on refcounted objects, and only use the GC for > strings and such. using an gc only as an drop-in-replacement limits its features. better design the applications from ground up for this. i'm thinking about an new development branch of glib - gcglib, which is completely gc based. anyone willing to join this project ? ~-n -- Enrico Weigelt == meTUX IT services software development, IT service, internet security solutions www: http://www.metux.de/ phone: +49 36207 519931 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
