Jeff, you need to read “Windows Internals, Fourth Edition”. Task Manager in XP is a big fat liar. Windows Vista’s Task Manager is not comparable.
The figure quoted as ‘available’ in XP is the sum of zero, free, standby and modified lists. The ‘system cache’ figure is the sum of the system cache working set (amount of physical memory used by the file system cache plus the physical memory used by pageable code and data in drivers, plus the kernel’s paged pool) and the standby and modified lists. Your screenshot shows the double-counting: Available + System Cache is 1.5 times physical memory!
When a page is taken out of (trimmed from) a working set, it isn’t immediately reused. Instead it is put on either the modified (if modified since last written to the page file or memory-mapped file it belongs to) or standby list. Links are kept from the process to the page. If the process then references the page again before it’s paged out, it causes a page fault to occur but Windows can satisfy it simply by fixing up the page table entry - this is termed a ‘soft fault’.
So how do pages get onto the other lists? Modified pages become standby pages by being written out to disk - a couple of background threads do this, mapped file pages are written after a maximum of five minutes on the list, and all pages start to be written after the modified list reaches 800 pages (about 3MB). Standby pages become free pages as the balance set manager (a thread that wakes up every second) runs, if the free list is too small. Finally, free pages become zero pages as the system zero page thread (runs at priority 0 and therefore only runs when at least one processor is idle) writes zeros to free pages.
When allocating physical memory Windows prefers zero pages for private user-mode page allocations, and free pages for kernel mode or mapped-file page allocations. (The use of zero pages is a security requirement to prevent processes being able to read other processes’ data). If the zero page list is exhausted, Windows will use the free list and zero the page on demand; if the free list is exhausted for a free page allocation, it will then use the zero page list. If both lists are exhausted it will then try the standby list - it then needs to unlink the page from its original process at this point - and in the pathological case that that is empty, it has to take a modified page, write it out, unlink it, zero it, and then give it to a process.
This is why these lists exist - Windows has done work when idle to ensure that there is physical memory available on demand.
Speaking of on-demand: when VirtualAlloc is called to allocate memory, no physical memory is actually allocated. The ‘commit charge’ is simply incremented. It reserves space in the page file to make sure it can’t overcommit on memory, but this reservation is a logical one - nothing is written to the page file. Only when a page is touched, and a page fault ensues, does a physical memory page get allocated (and the data loaded from disk if touching a memory-mapped file).
This commit charge is the value actually shown on the ‘PF Usage’ meter in XP’s Task Manager, and in ‘Commit Charge’ total. ‘Limit’ is the sum of all page files plus physical memory minus whatever Windows can’t page out.
There’s no limit to how large the standby list can grow. The file system cache has a limit on its virtual address size of approx 300MB IIRC, but since this is implemented as a working set, pages discarded from the cache go on the standby or modified list! However, if files are opened as sequential scan, they go on the front of those lists, not the end, so are likely to be reused more quickly.
While on the subject of Task Manager, the Process tab’s ‘Mem Usage’ column is actually the process’s working set. However, this includes a lot of shared pages from system DLLs, so the sum of ‘Mem Usage’ normally is significantly larger than physical memory. It’s impossible to tell if your program has a memory leak from this column. Switch on the ‘VM Size’ column (actually process private bytes) to monitor this, although this won’t necessarily drop when you free from a heap.
So XP normally has a lot of moderately-recently-referenced data sitting in memory (but not recently enough to keep it in the working set) - well, once the system has been running for a while. The difference is that Vista is actively preloading data that it thinks you might use soon.
It is legitimate to have a blog on BlgSpt, you know! (couldn’t post originally due to URL)