Re: Table Garbage Collection

[David Given <dg@...>]

Rob Kendrick wrote:
[...]
> Additionally, the reason for this is that the memory is allocated
> logically in a flat space, so if you have one block still allocated
> right at the end, but megabytes of free memory before it, this can't
> easily be returned to the OS if the memory was allocated by brk() (which
> extends the process's memory.)
> 
> What happens may be very different if the memory was allocated via
> mmap(), however.

glibc's allocator does use mmap() for large allocations, but that's not
particularly frequent (especially for Lua, which does lots of small allocations).

Beware: mmap() can only allocate complete pages. On Linux on IA-32, a page is
4kB, which means a 100 byte memory allocation will waste 3996 bytes of memory.
But on IA-64, a page is 4MB! Which means you're wasting a lot more.

A true embedded system typically doesn't do any dynamic memory allocation ---
the C or C++ part of the system will used statically allocated memory, and the
Lua part of the system will allocate memory out of a fixed-size static pool,
so this isn't normally a problem. It's only the medium-sized systems which are
bigger than embedded but too small for swap that suffer...

-- 
╭─┈David Given┈──McQ─╮ "A line dancer near a graduated cylinder, the
│┈ dg@cowlark.com┈┈┈┈│ blithe spirit inside some wheelbarrow, and a tomato
│┈(dg@tao-group.com)┈│ are what made America great!" --- received via spam
╰─┈www.cowlark.com┈──╯

Attachment: signature.asc
Description: OpenPGP digital signature