tags:

views:

125

answers:

1

Hi,

I've been trying to figure out how the malloc_info() function located in malloc.h works. I know you have to pass it a FILE* and that no options are implemented yet, but I am at a loss as to what it is actually reporting!? Furthermore i've written a test app that allocates a whole bunch of memory and the values reported from malloc_info() don't change, except when I did 20,000 1 byte allocations?

Is there anyone out there who has any experience with malloc_info() and can shed some light on what aspects of memory it is supposed to measure?

It should be noted that I could find next to nothing on google about malloc_info(), just some sketchy bug reports.

Example Output from malloc_info():

<malloc version="1">
    <heap nr="0">
        <sizes>
        </sizes>
        <total type="fast" count="0" size="0"/>
        <total type="rest" count="0" size="0"/>
        <system type="current" size="135168"/>
        <system type="max" size="135168"/>
        <aspace type="total" size="135168"/>
        <aspace type="mprotect" size="135168"/>
    </heap>
    <total type="fast" count="0" size="0"/>
    <total type="rest" count="0" size="0"/>
    <system type="current" size="135168"/>
    <system type="max" size="135168"/>
    <aspace type="total" size="135168"/>
    <aspace type="mprotect" size="135168"/>
</malloc>

EDIT:

As a further explanation; my fallback position is the mallinfo() function, but I was hoping to use malloc_info() as from what I can gather it is targeted to replace mallinfo(). What I've found is that mallinfo() and malloc_info() do not work the same. In my tests mallinfo() tracks all my allocations while malloc_info() fails to do so at all. I can only assume that malloc_info() is currently broken, or it is not intended to serve the same purpose as mallinfo().

In the article given by omnifarious there are good reasons that mallinfo() should be deprecated:

it is completely unsuitable for 64-bit machines. The data types required by the SysV spec don’t allow for values larger 2^31 bytes (all fields in the structure are ints). The second problem is that the data structure is really specific to the malloc implementation SysV used at that time.

However I think that at this time malloc_info() is not yet ready to take it's place.

FURTHER EDIT: After a bit more digging it seems that malloc_info() is reporting the arena size from mallinfo() in all places where 135168 appears (at least that's what it corresponds to). This seems much less useful and is a very one dimensional piece of information compared with what mallinfo() allows for.

+1  A: 

Large allocations are typically handled by just telling the OS "I need x number of memory pages.", often by mmaping /dev/zero. Allocations of larger than a page or 4 (A page is usualy 4096 bytes) are usually handled this way and those allocations are not things I'd expect a malloc diagnostic to track.

Unfortunately, I don't know anything more than anybody else about malloc_info. The LJ post about the removal of mallinfo (among other things), by Ulrich Drepper, our inestimable glibc author, appears to be the best information available, and that's pretty darned thin, and what you would've probably found with Google anyway.

The program I pasted at paste.lisp.org should run malloc through it's paces and print out the heap info. It's very Linux and gcc specific, but, of course, so is this question. Maybe fiddling around with the output of the test program will give you some insight into what it's talking about.

Omnifarious
With regard to your comment on large allocations; mallinfo() reports allocations using mmap as well as malloc, I was hoping malloc_info() would do the same...
radman
thanks for the tip about mmap being used for larger allocations it was quite instructive. On my system the threshold seems to be about 135kb, anything above that and mmap gets used.
radman
@radman - Interesting. I thought the threshold was much lower. So we both learned something. :-) I hoped my little multi-threaded program helped illustrate how the various pools are used. It's interesting to run it on a single core system.
Omnifarious