[Scummvm-devel] Dealing with memory fragmentation

[yotam barnoy]

Hi all

I'm working on reducing memory fragmentation when loading plugins
one-at-a-time. 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.

For the curious, we also get bad fragmentation in our current plugin
scheme, but since we reload all the plugins in the same order, they
generally occupy the same place in memory as they did before they were
unloaded and the fragmentation isn't felt too much. It rears its ugly
head, however, when the device's memory becomes nearly filled with
plugins. Subsequent allocations desperately fill the cracks between
the plugins, making the fragmentation severe.

Back to the one-at-a-time method: you can see in my recent commit that
I reduced fragmentation by taking the plugin out of memory as soon as
possible and by making sure more permanent allocations happen when the
plugin isn't loaded.

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'd appreciate your input.

Yotam