----- Original Message -----
From: "Christian Ohm" <[EMAIL PROTECTED]>
To: <warzone-dev@gna.org>
Sent: Thursday, December 28, 2006 4:52 PM
Subject: Re: [Warzone-dev] MALLOC/FREE issues
On Thursday, 28 December 2006 at 15:37, Troman wrote:
The issue of MALLOC was already raised in some of the previous
messages, and there seems to be something wrong with those MALLOC/FREE
macros. I noticed a memory leak in the scripting engine, to find out
what is actually causing it I set up a (script) loop with 10k
iterations with nothing but a string assignment in the loop body.
Due to the nature of this loop the interpreter was pushing
string/non-string data to the stack interchangeably, hence
allocation/deallocationg memory for strings. The memory usage went up
by ~3mb after each 10k iterations. I couldn't stumble upon any flaws
in the code, looks like MALLOC/FREE are causing this. Anyway, after
replacng MALLOC/FREE with malloc/free the memory leak is gone.
Apart from that I noticed WZ memory usage is increasing by about 35 mb
each time a skirmish game is restarted, it wouldn't surprise me if it
was due to MALLOC/FREE anomalies. Do we actually have to rely on
those two, ar would it make sense to simply replace them with
malloc/free? I remember someone (I think Per) was trying to rewrite
some functionality that dealt with wz memory usage that turned out to
be a non-trivial task, I hope it is not related to MALLOC/FREE.
https://lists.berlios.de/pipermail/warzone-dev/2005-September/000538.html
Is that what you meant? There were no actual problems mentioned.
That's probably it. I only caught the late resounding of this discussion.
A memory pool system has a few advantages: It's faster (ideally), it
prevents memory fragmentation (the underlying OS might try to do that as
well), and it can have some debugging functionality. Debugging could be
done by external tools like valgrind (though valgrind is sloooow).
Fragmentation is more a theoretical problem, and speed... well, malloc
is probably faster than a bad memory pool system.
I just had a quick look at wz memory management and if I got it right wz
marks FREEd memory and can reuse it whenever MALLOC is called again, I don't
quite understand why it consumed more and more memory, even though at the
time of my test there was nothing else that could have requested it.
We could replace MALLOC/FREE with a new (proven, so we need to find a
working GPL implementation) memory pool system, but the only real
advantage is built-in debugging, as long as we don't run lots of
mallocs/frees per frame. So I guess just ripping out the current system
(and leaving debugging to valgrind and other tools) and just using
malloc/free is a good start.
AFAIK valgrind is not available on windows, I don't know if there are any
good free tools available for windows comparable to valgrind, if there are
some though, then this shouldn't be an issue.
Troman
--
You can move the world with an idea, but you have to think of it first.
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
