I think you just said the same thing I did. I disagree. As I said, you get an approximation with wrappers. You can track the amount of memory actually in use by the client program. For malloc/frees that don't return memory to the OS once allocated (this includes glibc in Linux), you can also track the size of the free list consisting of memory that was already malloc()'ed at least once. As I also said, you can't track what's in block overheads. I omitted that you can't track free list memory that has never been allocated. Linux calls this the "trim threshold" and it's 128K by default. My experience is block overhead is about 8 bytes per block (unless you have turned on a debugging mode). So the wrapper normally gives a useful approximation.
My main point was the function of sbrk() is OS-dependent. I know malloc() _in Linux and Unix systems_ calls brk()/sbrk(). The article also talks about _how Linux glibc uses mmap()_ to allocate large chunks. Calls to mmap() do not affect the program break. Therefore sbrk(0) will not reflect these big blocks, so it's not a reliable way to estimate memory usage. Windows has a per process heap manager internal to the OS. So there is no sbrk(). There are other calls to query the amount of heap space in use. The documented way to get information about Linux memory usage is to read the special file /proc/<pid>/statm. See linux documentation for this. The documenated way to get information in Windows is GetProcessMemoryInfo(). On Nov 6, 12:17 pm, himanshu kansal <[email protected]> wrote: > @Gene: since the article itself says that if the memory is allocated > through malloc, it will make some (less) sbrk calls to the system to > increase the allocated memory to the program. > then how can a wrapper function will do.... > the malloc internally will call the sbrk function and will increase the > allocated memory....the wrapper func would have know way of finding that > the memory has been increased.... > secondly, it will ignore the amount of chunk that would have been used for > bookkeeping..... > > it cannot be done using wrapper function.... > > > > > > On Sun, Nov 6, 2011 at 3:18 AM, Gene <[email protected]> wrote: > > In C you can get close by wrapping malloc() and free() and maintaining > > your own total. This will not capture the header within each > > malloc()'ed block. > > > You can also use a tool like valgrind . > > > The behavior of sbrk() is totally OS dependent, and sbrk() doesn't > > exist on e.g. Windows. This method won't work reliably on Linux > > either. Here is a pretty good article for details on Linux memory > > allocation:http://www.linuxjournal.com/article/6390?page=0,0 > > > On Nov 5, 6:28 pm, himanshu kansal <[email protected]> > > wrote: > > > can we know the size of heap memory allocated to our program???? > > > > i think sbrk(0) will return the address of end of heap..... > > > but how to find the start of heap so that we can calculate the size of > > > total heap memory allocated to our program.... > > > > is there any way possible???? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Algorithm Geeks" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/algogeeks?hl=en. > > -- > > Regards > Himanshu Kansal > Msc Comp. sc. > (University of Delhi) -- You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/algogeeks?hl=en.
