[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Functions and memory usage
- From: John Donovan <JohnD@...>
- Date: Wed, 16 Oct 2002 17:12:55 +0100
I'm new to the list, and normally I'd just lurk for a couple of weeks
getting the feel for the list. However, time is of the essence at the
We're developing a game on a couple of well-known games consoles, and I've
been given the task of implementing a scripting system. After looking at
various options, I picked Lua. Now I'm trying to convince my boss that Lua
is A Good Thing. He's worried about memory fragmentation.
As most of you will be aware, consoles have a very limited amount of memory,
and I'm going to be given as small a piece of that as possible, so I've got
to make every byte count. After looking at the code, and how it allocates
and deallocates memory, we noticed that when it loads up a function (with
LoadFunction()) it loads locals, lines, constants, and code in that order.
However when it comes to free the function (with luaF_freeproto()) it does
it in a different order. My question is, if I shuffle the deallocation of
the memory LoadFunction() allocates so it does it in reverse order, could we
implement a second memory allocator that uses a simple stack? So when
LoadFunction() pushes locals, lines, constants, and code, we could safely
free it in reverse order without worrying if something else has realloc'd or
otherwise messed around with our function's memory?
A search of the archives turned up nothing on this specific question, but I
have noticed that fragmentation is a reported problem that some people have
managed to keep to a minimum.
Programmer - Magenta Software Ltd.
The content of this message and any attached file are confidential and/or
privileged and are for the intended recipient only. If you are not the
intended recipient, any unauthorised use, disclosure, copying, distribution
or other dissemination is strictly prohibited. If you receive this message
in error please notify the sender immediately by email, telephone or fax and
then delete this email. Any attachment with this message should be checked
for viruses before it is opened. Magenta Software Limited cannot be held
responsible for any failure by the recipient to check for viruses before
opening any attachment. Copyright in this email and attachments created by
us belongs to Magenta Software Limited. Should you communicate with anyone
at Magenta Software Limited by email you consent to us monitoring and
reading any such correspondence.