[Scummvm-devel] Dealing with memory fragmentation

[yotam barnoy]

>
> 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 :).
>

I don't see another way to deal with the problem other than
instantiating new hashtables and copying into them -- we already have
the assign() method for that. Yes, it'll create some minimal
fragmentation, but that'll quickly get filled up either by other
stuff. By double copy, do you mean instantiate, copy, then copy back
so as to take more or less the original space?

I thought of making something like a CompactingSingleton with the
compact() method you mention because we could have the same issues
with other classes such as KeyMapper, if it ever gets finished.

Also, I think even garbage collection wouldn't help with this problem
unless we made a whole allocation system that moved things around in
memory sort of the way DW2 did way back. And I think we really don't
want to do that :) In this case, the problem isn't garbage but active,
long-term allocations.

Yotam