lua-users home
lua-l archive

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

2008/12/4 "O. Wölfelschneider" <>:
> Say I have a C function like this:
> int new_fnord(lua_State *L) {
>  struct fnord_t *fnord = alloc_fnord();
>  struct fnord_t **fnord_p = lua_newuserdata(L, sizeof(struct fnord_t *));
>  *fnord_p = fnord;
>  luaL_getmetatable(L, "FNORD_METATABLE");
>  lua_setmetatable(L, -2);
>  return 1;
> }
> (Error handling not shown.)
> (Metatable contains __gc to clean up at GC time.)
> Now imagine that alloc_fnord() grabs a large chunk of memory and is outside
> of
> my control (Lua-unaware external library).
> As lua is concerned, it's got only one pointer of a few bytes to worry
> about,
> since it cannot know that there is actually a big memory footprint behind
> it.
> After a lot of calls to new_fnord(), the program has grabbed a huge amount
> of
> memory while lua still doesn't see a reason to garbage collect, since, hey,
> it's just a few pointers...
> Can I somehow tell the garbage collector that new_fnord() allocates big
> time?
> Currently I'm calling collectgarbage("collect") every now and then, but this
> doesn't feel right.
> BTW: In this application, lua is running on an embedded ARM with 32MB and a
> fnord_t actually caches an unpacked GIF animation. Having these pending GC
> eats up the little memory quickly.

If you want Lua to manage the memory allocated by that library, you
can write a custom allocator that you would pass to that library. The
allocator would allocate the big chunk of memory as a Lua userdata.
That way the Lua garbage collector would be aware of it. You can then
tell the GC about the dependency between your small userdata (the one
you already have with just a pointer) and the big one (the memory
chunk) with environment tables.