[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: GC and memory management
- From: "Julien Patte" <julien.patte@...>
- Date: Fri, 30 Jun 2006 16:22:19 +0200
Hello,
I'm currently working with Lua on an embedded system (a graphic calculator).
The Lua programs may use approximately 180 Ko, which is rather limitated for some large scripts (e.g. scripts written to solve some complicate numerical problems). Thus, I must prevent the interpreter of using too much memory, and force it to collect tables and userdata's as soon as possible.
I tried to change the parameters of the GC with lua_gc(), but I couldn't obtain the results I want. My current solution consists of using the hook I already set (to periodically check for external events), to perform a complete GC cycle.
I have something like
static byte gcCount=0;
void myHook(lua_State* L, lua_Debug* ar)
{
(...)
gcCount++;
if(gcCount>200) { lua_gc(L,LUAGC_COLLECT,0); gcCount=0; }
}
My hook is set with:
lua_sethook(L, myHook, LUA_MASKCOUNT, 20);
This gives me good results, because the script only uses the memory it needs, but this method may slow down its execution. I'd like to know if there is a way of having the same kind of behaviour by simply changing the parameters of the GC. My problem is that the GC isn't aggressive enough and the programs may reach the limit quite easily, even with some low/high values for "pause" and "step".
Also, something I don't really understand: If there isn't enough memory, my allocator function can detect it and return NULL. Then the interpreter raise an error and the execution breaks softly. But in that case why doesn't the interpreter try to perform a GC cycle, then try to allocate memory again? Most of the time a part of memory may be safely freed and this allocation shouldn't break the program.
Would it be safe to manualy call the GC in the allocator function in case of failure?
Thanks for your help,
Julien