[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How to best solve fragmentation issues
- From: Asko Kauppi <askok@...>
- Date: Mon, 25 Feb 2008 18:44:19 +0200
Did you run the collect cycle _twice_, when trying it?
See the Lua reference, part of the releases only happen after the
second gc call.
Jens Andersson kirjoitti 25.2.2008 kello 18:27:
Thanks for all the good suggestions about this problem. Writing a
allocator like suggested seems like a decent solution. I did try
approach first though: I remade my program so that there is a
during execution where I can free all dynamic allocations. After
implementing that I still had fragmentation issues, so after logging
remaining allocations between two runs a bunch of LUA allocations
Since I doubt there are memory leaks in there, I assume that I do
wrong, but a call to lua_close() should free up all dynamic
shouldn't it? I also tried a lua_gc(L, LUA_GCCOLLECT, 0) call before
the state, but that didn't affect anything.
[mailto:email@example.com] On Behalf Of Stephen
Sent: den 22 februari 2008 17:13
To: Lua list
Subject: Re: How to best solve fragmentation issues
Jens Andersson wrote:
separate heap. I'm not really looking forward to implement a separate
memory-manager, but this way the LUA allocations won't interfere
rest of the memory.
Is there a better way to solve this?
You may be better off writing a C extension that provides an API that
simply allocates one large chunk of memory and then
allocates/deallocates that memory explicitly. Four functions should
allocate from heap
deallocate from heap
This removes you from the problem of having to write a full blown
manager to replace the Lua one, plus the problems of making your
memory manager as fast as the general purpose one (your simple cases
be faster, but the nasty cases will most likley be worse, or just
It also means that if your images are all the same size or you know
largest size of the images and how many images you'll need at any one
time you can ensure your heap has this space and also ensure that your
allocate()deallocate() functions prevent fragmentation.
I know I'm advocating explicit memory management in a GC'd world. But
for things like this its almost certainly a better bet. I've come
some similar cases in the Windows world (where you can force the
with VirtualAlloc/VirtualFree or
HeapCreate/HeapDestroy/HeapAlloc/HeapFree). The C allocator will never
give you the control so that you can guarantee the result.