Hi all, as some of you may have been noticing I've spent some time on analyzing high memory use of Gnash during execution of potlatch. Full story here: http://savannah.gnu.org/bugs/index.php?28009
The problem is many AS objects are allocated in a loop (around 3500 iterations) and are only destroyed at the very end of actions execution. The amount of memory allocated by the end of action execution is over 1Gb. The GC run properly drops most of these objects (altought memory isn't released to the system, despite GLIBCXX_FORCE_NEW). Now, beside the release of resources to the system, which at this point is secondary, what's interesting is that running the GC earlier can keep the memory much much lower. For example, with the testcase attached to the bug we can from 723mb to 260mb. The problem is that running the GC is very expensive as we need to scan all reachable objects. Currently the only heuristic to avoid GC runs is based on the number of collectable resources allocated since last run, which defaults to 50 and can be changed by exporting the GNASH_GC_TRIGGER_THRESHOLD environment variable. Can anyone think of other strategies to decide *when* to run the GC ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
