Re: Memory leaks / Help with memprof & ps output
- From: Enrico Weigelt <weigelt metux de>
- To: gtk-list gnome org
- Subject: Re: Memory leaks / Help with memprof & ps output
- Date: Tue, 9 Apr 2002 19:10:51 +0200
On Tue, Apr 09, 2002 at 03:32:32PM +0100, John Cupitt ng-london org uk wrote:
> Here are two mails from Havoc about the GC version of gtk.
> 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
> 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 ?
> - 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 ?
Enrico Weigelt == meTUX IT services
software development, IT service, internet security solutions
www: http://www.metux.de/ phone: +49 36207 519931
email: contact metux de cellphone: +49 174 7066481
] [Thread Prev