RE: Functions and memory usage

[John Mckenna <jmckenna@...>]

From: Basile STARYNKEVITCH [mailto:basile@starynkevitch.net]

>However, if you feel that fragmentation is an issue:
>
>1. you cannot use traditional manual memory management (ie malloc+free
>   or new+delete) because it has the same fragmentation problem.

That's not entirely true.  If you're doing manual allocation, you can
control when each allocation is done.  If you're careful about how you
do things, you can avoid fragmentation.  It requires a detailed plan
up front, and a big stick to beat programmers who break it.

View memory as a stack, and forbid freeing anything until everything
that was allocated after it has been freed.  You can be a bit more
flexible than that - use a stack of states, and insist that each state
frees all of the memory it allocated before it leaves.

With garbage collection, being careful doesn't help.  It might be a
while before the system notices that a block is no longer in use.  By
then you might have allocated new blocks beyond it, fragmenting memory.

I suppose you could force a collection on each state transition.  That
might work.  You still need discipline, of course.  And a big stick. 

Whichever language you use, patch its memory allocation routines so you
can produce a log of all allocation: where, how much, and who did it.
We have an off-line graphical viewer that nicely shows where fragmentation
occurs, and who to blame.  It's much easier to do this in Lua than in
C++.

>2. you should consider compacting or moving garbage collection
>   techniques, which do have some drawbacks (in particular, real-time
>   or interactive-time constraints may require tricky tradeoffs or
>   tuning with such moving GCs).

You mean spend CPU time on something that's not directly related to
the game?  Heresy! :-)

John
-Virus scanned and cleared ok