[Scummvm-devel] Dealing with memory fragmentation

[Max Horn]

Hi Yotam!

Am 08.11.2010 um 09:42 schrieb yotam barnoy:

> Hi all
> 
> I'm working on reducing memory fragmentation when loading plugins
> one-at-a-time.

Really cool :).

> This is critical since we load, unload and reload into
> the same memory space. Bigger plugins don't fit into the same place in
> memory that smaller plugins were in, and this can cause small devices
> to quickly run out of memory.
> 

[...]

> I could use some help with coming up with a solution for one big
> source of fragmentation -- ConfigManager. It's not an issue while a
> plugin isn't loaded (e.g. in the launcher), but it becomes an issue
> when an engine adds things to its domain while running. Strings will
> be allocated on the heap that outlive the plugin. In addition, it's
> possible that either the memory pool of the hashmaps will need to
> expand by allocating another page (which will *never* be deallocated)
> or that a hashmap's storage will need to expand.
> 
> My idea was that after returning to the launcher and unloading a
> plugin, ConfigManager will copy itself over and destroy its old
> instance. This will ensure that all of its storage space is not
> allocated after the plugin in memory. I'm not sure what the best way
> is to realize this. Perhaps this problem exists in some other classes
> as well, and we should make this functionality fairly generic -- maybe
> even put it in Singleton or a derivative thereof.


I don't think putting this into singleton is a good idea, as then we'd have to allow copies of singletons, which kind of defeats the purpose of a singleton. We'd then also have to make sure all and every singleton is properly copyable (at least we should, even if we never "intend" to copy that particular singleton -- tomorrow's developer won't know that, after all).

Also, do we really need to copy the whole singleton? This would also not solve fragmentation completely, it can even cause more (albeit hopefully relatively small) fragmentation, as the old manager would still be in its original place (near the start of the heap), so the new instance would have to sit farther down the heap; and when we release the original config, it'll leave a gap.
We could try to avoid this by a "double copy"...


Anyway, instead of copying the whole config manager, we could also add a compact() method to it. That then could do a (double) copy on the config manager members; and/or it could invoke (to be written) compact() methods on the hashmaps, memorypools etc. in it. 
Oh, and feel free to improve memorypool, it is currently very crude and simplistic :).

Ah well, all these problems would not exist if we were using a garbage collector! :) We'd have new problem then, of course (like, increased CPU and memory footprint :). 


Bye,
Max