On 12/14/09 15:34, strk wrote:
Can anyone think of other strategies to decide *when* to run the GC ?
Back when I worked on LISP systems (25 years ago), the GC would run
in a separate thread based on a timer, as opposed to any other action.
Each object was tagged as to it's state, and the GC would just remove
anything with the appropriate state. Some customers of mine back then
would often play games with the time slice for the GC to get the optimal
memory uses. (back then memory was still expensive)
This might not help in this case, unless the objects are tagged as
unused before the action is complete. I'm not exactly suggesting we do
it this way, I haven't really thought through how it would work in
Gnash, but you did ask for other ideas... :-)
Just as a note, there is some other memory profiling built into Gnash
that uses mallinfo() to get memory stats from the kernel. There are also
some utility functions in gmemory.h like startCheckpoint(),
endCheckpoint(), to get finer grained info of where memory was going. I
also added support to jemalloc to support mallinfo() as well.
Out of curiosity, did you run your tests with or without jemalloc ?
It's better tweaked for all the small allocations of memory that an OOPS
language uses.
- rob -
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
