Profile memory based on virtual memory and resident memory seperately

[GoogleCodeExporter]

There're occasions that a large block memory is allocated but only a part of it 
is used. 
memory usage profile can't reflect the actually memory usage in this situation.

When dumping the memory report to disk, it can be done this way so that each 
memory page is checked to be residual or not, and summarized accordingly.

Original issue reported on code.google.com by yufanyu...@gmail.com on 1 Jun 2011 at 6:12

[GoogleCodeExporter]

I doubt we'd be extending the existing heap profiler with that kind of 
information.  If you're interested in doing it, you could write a simple 
program to do it, by using the MallocHook infrastructure.

While it's hard to say without a motivating example. it seems to me that the 
information you're looking for is either already present in 
MallocExtension::instance()->GetStats(), or else application-specific enough 
that writing your own routine to collect the exact data you need is the best 
way to go.  

Original comment by csilv...@gmail.com on 1 Jun 2011 at 6:20

• Added labels: Priority-Low, Type-Enhancement

[GoogleCodeExporter]

Taking std::vector as a example, it always double it's capacity to hold more 
data,
but the newly resize vector won't take residual memory until it's actually 
accessed.
So residual and virtual memory will have 50% difference at most. It's a big 
difference.
For application use a lot container or buffer like this, It's very necessary to 
distinguish both type of memory usage.
I hope this can be bump to "Priority-Medium".

Original comment by yufanyu...@gmail.com on 1 Jun 2011 at 8:13

[GoogleCodeExporter]

The situation is a lot more complicated than you describe, and depends on 
things such as the operating system being used and the OS page size.

Again, if all you care about is how much memory is actually resident in an 
application at a given point in time, the malloc-stats that I mentioned earlier 
will give it to you.  If you need something else, it's probably specific enough 
you'll want to write it yourself.

Original comment by csilv...@gmail.com on 1 Jun 2011 at 6:12

[GoogleCodeExporter]

Haven't heard anything in a while, so closing.  I believe the information in 
question is already available, either through an appropriate malloc-extension 
call, or by asking the OS (depending on exactly what data is wanted).

Original comment by csilv...@gmail.com on 18 Oct 2011 at 6:24

• Changed state: WontFix