In current HEAD, the Gnash garbage collector is enabled by default. The collector will only take care of as_object instances, while other previously ref-counted objects (character_def, font, bitmap_info, ...) remain ref-counted, not suffering from the circular dependency problem.
The collector is invoked at FPS rate, but will not do anything unless 10 new collectible resources have been registered since last run. This quick and dirty heuristic resulted in a comparable speed between the GC and RC model for the CreativeCommon movie. See http://gnashdev.org/wiki/index.php/ProfilingGC The next step would be broader testing. We want to test: - Find memory corruptions due to the GC (if you disable the GC and the segfault/assertion failure is still there it's not GC-related) - Try out your known-to-be-leaky movies to see how the GC copes with them. Next steps would be: - Leak analisys (ie: any leak left to plug?) - Cleanup the code by removing the no-more needed resource marking functions implemented when character_def and fonts and other then as_object classes were also garbage-collected (this might slighly improve performances, as those marker are still called, altought mostly inlined no-ops) - Discuss introduction of a smart pointer type for storing collectible objects (we currently use intrusive_ptr with no-op add_ref/release functions) Stay tuned on http://savannah.gnu.org/task/?7009 for more info. --strk; () ASCII Ribbon Campaign /\ Keep it simple! _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
