Re: [Gnash-dev] GC: status report & call for test

[strk]

On Tue, Jul 03, 2007 at 10:46:32AM +0200, Udo Giacomozzi wrote:
> Hello strk,
> 
> Tuesday, July 3, 2007, 12:57:53 AM, you wrote:
> s> The collector is invoked at FPS rate, but will not do anything unless
> s> 10 new collectible resources have been registered since last run.
> s> This quick and dirty heuristic resulted in a comparable speed between
> s> the GC and RC model for the CreativeCommon movie.
> s> See http://gnashdev.org/wiki/index.php/ProfilingGC
> 
> Correct me if I'm wrong, but any function *call* causes registration
> of at least 2 GC resources (reference to self in the call stack). So,
> 5 calls to functions in one frame will cause the GC to run at frame
> time. At the other hand, these *are* resources that can only be freed
> by the GC (circular reference)...

I'm not sure how many GC resources are registered in a function call.
Setting GNASH_GC_DEBUG to a value > 1 should notify every registration.

> (I am already thinking about optimization). What about a combined
> RC/GC-method? Use refcounting to free a resource immediately, when it
> can't be reached for sure and let the GC do it's work for the
> resources that won't be freed with the RC method.

Would not be a speed improvement, just a memory footprint one,
and I think we don't have good profiles for memory yet to decide
whether this is worth now.

> Anyway, the new GC performance nearly reaches the RC speed. :)

Try tweaking that number of newly registered collectible and I'm sure
it would be faster :)

> Can threading (movie loading in background) be enabled now?

Sure ! NOT collecting definitions did the trick, and in case a thread
which is not the main one attempts to register a resource with the GC
an assertion would fail.

> s>         - Leak analisys (ie: any leak left to plug?)
> 
> After *many* thousand frames I see a slightly higher memory
> consumption, so there may be a *tiny* leak somewhere. Not a big deal.

I'm seeing this too. First of all export GLIBCPP_FORCE_NEW (or GLIBCXX_FORCE_NEW
foro gcc 3.4 +) to avoid the standard allocator to use memory pools.
Then build gnash with GNASH_GC_DEBUG set to 1 (so you see if there's an 
increment
of registered collectible or the leaking object is NOT a GcResource).

I still know there are leaks in other places, and if you see the code you
understand why (unexisting ownership documenattion). OpenGL leaks more,
but some leaks are in the core. button_action has some leaks too.
I'm doing cleanups as I can currently, using valgrind to find definitely
lost pointers. Note that this is not enough, as for example opengl (the
code contains a TODO comment I belive was yourse) keeps caching things
w/out ever cleaning the caches.

--strk;