lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


If I could use multiple VMs, I'd just shut down the one I have and restart it. The problem is that some state data needs to be shared, and while I know there's lots of possibilities, all are ugly at this point.

Does anybody know if there any tech docs available on how Lua is implemented? I find the source isn't very easier to "read"...

Thanks,
Brett

----- Original Message ----- From: "Richard Ranft" <rranft@lvcablemodem.com>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Saturday, July 01, 2006 11:41 PM
Subject: RE: Memory woes


This might be useless, but why not simply start a new Lua VM when leaving
the menu to start the game, then dump the menu VM.  On game exit, start a
new Lua VM again for the menu and just drop the old "game" VM. I can't see
how this would take any longer than dumping all scripts and then loading a
new set at each transition. Unless memory allocation is so dreadfully slow on the PS2 that it makes retaining the memory pool across states mandatory.

Just a thought, and probably not something you haven't already thought of.

Rich


Subject: Memory woes


We have a PS2 game that is in Beta and close to shipping now and
I'm still
having trouble tracking/controlling Lua's memory usage. Any tips would be
greatly appreciated.

Notes:
1. We use Lua 5.0.3 to script the entire game. Each script is an
object that
is loaded, run and collected individually as needed. We are loading a few
hundred lua scripts for the non-game, once the player starts the game we
unload all of these, and load a few hundred game scripts. Once game ends,
reverse and repeat the process.

2. We do a memory dump from main menu, then run the game, then
exit the game
and do another dump from the main menu. Each time we do this
cycle, memory
associated with Lua has increased 145KB to 155KB. The things
(quantity and
exact items) being loaded both in game and out are fixed.

3. We do manual garbage collections after all unloads, prior to
loads, and
once again after the load has completed.

4. We have verified that the exact same objects are in memory at each
snapshot.

5. We dumped the globals and registry tables and verified that the exact
same keys are in lua at each snapshot.

6. The memory reported by lua as being in use doesn't change much
(a few KB
between runs).

7. Our internal memory manager traps all lua allocations and tags
them so we
know they are coming from lua. The increase in memory is memory
used only.
Fragmentation wouldn't effect the number.

8. Shutting down lua and restarting it isn't an option this late in the
project.

Debugging Lua isn't the easiest thing I have ever done. If anybody can
suggest any additional checks or debugging strategies it would be greatly
appreciated.

Are there any code commentary docs anywhere that explain the internals of
Lua?

Thanks,
Brett