Re: Question about Lua 5.1.3 and realloc() on life.lua

["Bogdan Marinescu" <bogdan.marinescu@...>]

Thanks for your advice. I don't need to save the block size, Lua calls
its allocator function with both the old size and the new size of the
block. Free bookkeeping for me. Also, when the block is downsized, I
never move memory, I just add another free block after it if needed.
Regarding the upsizing, that's exactly what I want to try. This is not
really the point though, the chained allocator was just a "didactic"
attempt, I'm more and more convinced that low-fragmentation allocators
such as dlmalloc() are a much better choice for Lua. Fortunately,
dlmalloc is what Newlib uses, so at least ARM platforms are OK, since
all the ARM embedded toolchains I know use Newlib. And yes,
percentages are good :)

On Fri, May 2, 2008 at 11:49 AM, Alex Davies <alex.mania@iinet.net.au> wrote:
>
>
> > Specifically, I can see lots and lots of realloc calls with a one byte
> difference between the old block size and the new block size, in both
> directions (+1 or -1 difference).
>
> When implementing your allocator, save the block size away with the block
> returned. And then when a block is downsized, if it's within 16 bytes or 25%
> of the allocated size, don't move it - just downsize "in place". Similarly
> when upsizing, if it cannot be satisfied in place add say 50% to the new
> block size. Such heuristics minimize memory moves and fragmentation quite
> nicely. Note, it's wise to use percentage sizes along with minimum deltas.
> Otherwise you're only fixing the problem for small resizes.
>
> - Alex