[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Table Garbage Collection
- From: David Given <dg@...>
- Date: Thu, 23 Nov 2006 15:50:01 +0000
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
ââ firstname.lastname@example.orgâââââ blithe spirit inside some wheelbarrow, and a tomato
ââ(email@example.com)ââ are what made America great!" --- received via spam
Description: OpenPGP digital signature