Re: memory allocation policy
- From: Javier Guerra Giraldez <javier@xxxxxxxxxxx>
- To: LuaJIT <luajit@xxxxxxxxxxxxx>
- Date: Wed, 24 Sep 2014 16:05:41 -0500
On Wed, Sep 24, 2014 at 3:50 PM, Cosmin Apreutesei
<cosmin.apreutesei@xxxxxxxxx> wrote:
> I think he means implementing a pool in Lua, so the function you pass
> to ffi.gc() is Lua all the way down.
i think the solution has more than one part (both are in Mike's answer)
1.- release resources as soon as possible. The issue (and this
happens both in Lua and LuaJIT), is that Lua only sees very small
objects, barely bigger than a pointer; so there's not much pressure to
collect garbage. The solution is to add some 'release' method to your
objects and call them the moment they're not needed.
2.- (de)allocators are slow, and LuaJIT don't compile calls to __gc.
But if you don't wait for the GC to release, you can do much faster.
What we do in SnabbSwitch is to allocate a big FFI array and then
handle freelists (just an array of pointers to the elements). just
getting an element from the freelist and returning it later is _much_
faster than any general-purpose allocator, no garbage is generated and
there's no fragmentation.
--
Javier
Other related posts:
