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

[Udo Giacomozzi]

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 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.


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


s> The next step would be broader testing.

s> We want to test:

s>         - Find memory corruptions due to the GC
s>           (if you disable the GC and the segfault/assertion
s> failure is still there it's not GC-related)

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


s>         - Try out your known-to-be-leaky movies to see how the
s>           GC copes with them.

Very good! I use this shell command to watch memory usage:

  while :; do cat /proc/$(pidof lt-gnash)/statm ; sleep 1 ; done

Using RC the penultimate value (data/stack) continously raises, with
GC is stays still.


s> Next steps would be:

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.




Well done! :)

Udo