How does Windows know i'm not using the memory?

Question

I noticed this weird effect where memory is not registered as allocated by the Windows Task Manager until it is touched instead of when it is malloc-ed or new-ed. The effect occurs in both the debug and optimized release builds.

The following is a structural example, although in my code the allocation and utilization occurs on different threads so I don't think its the optimizer, although I am not sure how to check.

for (int i = 0 ;i < 1000;i++)
{
buffer[i]=malloc(buffersize);
}
_sleep(1000*60)
for (int i=0;i<1000;i++)
{
memset(buffer[i],0,buffersize);//Only shows up the in the resource manager here
}

My question is how does Windows know I have used the memory? Is it monitoring memory for first usage or is it some compile time optimization.

My curiosity is motivated by a realtime acquisition I am writing that requires me to touch the memory twice -> once when allocating and once when actually filling it with data. Thus pressing a button ("aquire!") requires me to write 64 gigabytes of ram at once, as opposed to over time, adding a fairly real amount of latency. If I malloc as I go this adds too much latency.

--edit--

I also disabled the Windows pagefile...

Answer 1

This is standard behavior for a demand-page virtual memory operating system like Windows. The malloc() call only allocates virtual memory address space. You don't actually start using RAM until you access the memory. Which generates a page-fault, forcing the operating system to map the memory page you accessed into RAM.

This is normally a soft page fault, handled very quickly by grabbing a RAM page off the free list and mapping it. As opposed to a hard page fault, one you'll suffer later when some of those RAM pages got swapped out again to the swap file because another process needed RAM. Reloading the page from disk takes more time.

Disabling the paging file helps avoid those hard page faults. It doesn't eliminate them, your code pages are subject to getting swapped out as well. Which may well happen when you force the OS to fall back to them since it can't swap out to the paging file anymore. Such a page is just discarded when swapped out, reloaded from the executable file when page-faulted back in.

If you have soft realtime requirements then the best strategy is to allocate memory early and intentionally access it before you start to promise quick responses. Could simply be done with calloc() instead of malloc().