I think its same as the Virtual memory

On Mon, Nov 7, 2011 at 4:22 PM, Gene <[email protected]> wrote:

> 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.
>
>

-- 
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.

Reply via email to