10-19-07 06:32 PM
On Oct 19, 2:11 am, Bin Chen <binary.c...@gmail.com> wrote:
> Hi,
>
> I know if I call free, the glibc may or may not free the memory to the
> OS, but I want to do a profile on an application which need a exact
> stat of memory usage, can I tell libc to not buffer any free, but
> direct every free to OS layer? So I can use ps/top to know the memory
> usage.
This is usually not possible.
To understand why, you need to know a little about memory management
on Unix. Historically, a process had a single contiguous block of
memory. To allocate more, you use the sbrk() system call, which
extends the block, adding additional space to the end. This is how
malloc() gets memory from the OS. Now it is usually also possible to
call sbrk() with a negative number, which shrinks the block and
returns the excess to the operating system. But this means the only
way that free() could return memory to the OS would be if the freed
chunk happened to be right at the end of the program's block. So in
practice this would only work if you freed chunks in the reverse order
that you allocated them. Also, if you later malloc'ed something else,
malloc() would just have to ask for that memory right back again, at
the cost of another system call. Since the savings are minimal and
the overhead significant, most malloc() implementations don't bother
trying to return the memory, instead keeping it in the process to be
used by future calls to malloc().
Nowadays there is another mechanism: mmap() can be used to allocate
blocks of memory from the OS at arbitrary addresses, which can later
be freed by munmap(). But the blocks must be in multiples of the page
size (usually 4K or 8K). Some malloc() implementations use this for
large allocations, and then it would be easier to free them later.
But for smaller allocations you'd have to pack them together, and if
you wanted to munmap() later you'd have to do extra bookkeeping to
know when the whole block was no longer used. Again, usually not
worth the trouble.
I think you should instead look to gather your statistics from
malloc() directly. The glibc malloc has a lot of options; it's likely
that it has a way to report how much has been allocated. It's well
documented in the glibc manual (run "info glibc"). This stuff is
probably not in the man page for malloc(3). You could also write your
own wrapper around malloc()/free() that collects the information you
want.
[ Post a follow-up to this message ]
| 
