Is there a way to tell libc to do immediate free to OS? - Unix

This is a discussion on Is there a way to tell libc to do immediate free to OS? - Unix ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Is there a way to tell libc to do immediate free to OS?

  1. Is there a way to tell libc to do immediate free to OS?

    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.

    Thanks.
    Bin


  2. Re: Is there a way to tell libc to do immediate free to OS?

    On Oct 19, 2:11 am, Bin Chen 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.


+ Reply to Thread