What exactly is memory usage?

[Walter Bright]

Serg Kovrov wrote:
> Walter Bright wrote:
>> If those tools are measuring physical memory, that has no connection 
>> to whether memory is returned to the operating system or not.
> 
> Private Bytes is a virtual memory counter.

You might find this helpful from 
http://blogs.msdn.com/ricom/archive/2005/08/01/446329.aspx :

"The Private Bytes counter reports the commit charge of the process. 
That is to say, the
amount of space that has been allocated  in the swap file to hold the 
contents of the
private memory in the event that it is swapped out.  Note: I'm avoiding 
the word "reserved"
because of possible confusion with virtual memory in the reserved state 
which is not
committed.

So, if we are concerned with space allocated in the swap file then the 
Private Bytes counter
is right on the money.  However, that is not usually what we are 
concerned about.  We're
much more interested in memory pressure caused by copies of private 
bytes in multiple
processes.  That is to say we are concerned about the physical memory 
that has been allocated
to hold those private bytes.

Why might/does the operating system allocate space in the swap file to 
hold the contents of
memory whose contents have never become resident and may never become 
resident?  The answer
is not actually so complicated:  Windows cannot deliver an "out of 
memory" exception/error
just because you tried writing to, for instance, a static variable.  The 
swap space must be
pre-allocated at a reasonable time (such as loading a DLL) so that we 
can deliver an error
result at a reasonable time -- the time at which the virtual addresses 
changed from
reserved to committed.

So if we had some static data that could be modified, but usually isn't 
modified in
practice, and maybe isn't even read, you would find that the Private 
Bytes counter
overstated the cost of that storage.  The only real cost is the small 
bit of housekeeping
to track allocated space in the swap file.  No private memory need be 
allocated.

In contrast, the output of vadump deals directly in what is resident and 
so, if memory is
tight, it may understate the true memory cost because some things may 
have already been
swapped out by the time you ask for the current resident pages. 
However, if memory is
abundant then swapping is not going to happen and you can get a true 
picture of all the
required pages from vadump."