title: Committed vs Reserved Memory
body: <p>According to "<em>Windows Internals, Part 1</em>" (7th Edition, Kindle version): </p>
  
  <blockquote>
    <p>Pages in a process virtual address space are either free, reserved, committed, or shareable.</p>
  </blockquote>
  
  <p>Focusing only on the <code>reserved</code> and <code>committed</code> pages, the first type is described in the same book:</p>
  
  <blockquote>
    <p>Reserving memory means setting aside a range of contiguous virtual addresses for possible future use (such as an array) while consuming negligible system resources, and then committing portions of the reserved space as needed as the application runs. Or, if the size requirements are known in advance, a process can reserve and commit in the same function call.</p>
  </blockquote>
  
  <p>Both reserving or committing will initially get you entries in the VADs (virtual address descriptors), but neither operation will touch the PTE (page table entries) structures. It used to cost PTEs for reserving before Windows 8.1, <a href="https://devblogs.microsoft.com/oldnewthing/20160701-00/?p=93785" rel="nofollow noreferrer">but not anymore</a>.</p>
  
  <p>As described above, <code>reserved</code> means blocking a range of virtual addresses, NOT blocking physical memory or paging file space at the OS level. The OS doesn't include this in the commit limit, therefore when the time comes to allocate this memory, you might get a surprise. It's important to note that reserving happens from the perspective of the process address space. It's not that there's any physical resource reserved - there's no stamping of "no vacancy" against RAM space or page file(s).</p>
  
  <p>The analogy with plots of land might be missing something: take <code>reserved</code> as the area of land surrounded by wooden poles, thus letting others now that the land is taken. But how about <code>committed</code> ? It can't be land on which structures (eg houses) have already been build, since those would require PTEs and there's none there yet, since we haven't accessed anything. It's only when touching <code>committed</code> data that the PTEs will get built, which will make the pages available to the process.</p>
  
  <p>The main problem is that <code>committed</code> memory - at least in its initial state - is functionally very much alike <code>reserved</code> memory. It's just an area blocked within VADs. Try to touch one of the addresses, and you'll get an access violation exception for a <code>reserved</code> address:</p>
  
  <blockquote>
    <p>Attempting to access free or reserved memory results in an access violation exception because the page isn’t mapped to any storage that can resolve the reference</p>
  </blockquote>
  
  <p>...and an initial page fault for a <code>committed</code> one (immediately followed by the required PTE entries being created).</p>
  
  <p>Back to the land analogy, once houses are build, that patch of land is still <code>committed</code>. Yet this is a bit peculiar, since it was still <code>committed</code> when the original grass was there, before the very first shovel was excavated to start construction. It resembled the same state as that of a reserved patch. Maybe it would be better to think of it like terrain eligible for construction. Eg you have a permit to build (albeit you might never build as much as a wall on that patch of land).</p>
  
  <p>What would be the reasons for using one type of memory versus the other ? There's at least one: the OS guarantees that there will be room to allocate <code>committed</code> memory, should that ever occur in the future, but doesn't guarantee anything for <code>reserved</code> memory aside from blocking that process' address space range. The only downside for <code>committed</code> memory is that one or more paging files might need to be extended in size as to be able to make the commit limit take into account the recently allocated block, so should the requester demand the use of part of all the data in the future, the OS can provide access to it.</p>
  
  <p>I can't really think how the land analogy can capture this detail of "guarantee". After all, the <code>reserved</code> patch also physically existed, covered by the same grass as a <code>committed</code> one in its  pristine state.</p>
  
  <p>The stack is another scenario where <code>reserved</code> and <code>committed</code> memory are used together:</p>
  
  <blockquote>
    <p>When a thread is created, the memory manager automatically reserves a predetermined amount of virtual memory, which by default is 1 MB.[...] Although 1 MB is reserved, only the first page of the stack will be committed [...]
     along with a guard page. When a thread’s stack grows large enough to touch the guard page, an exception occurs, causing an attempt to allocate another guard. Through this mechanism, a user stack doesn’t immediately consume all 1 MB of committed memory but instead grows with demand."</p>
  </blockquote>
  
  <p>There is an answer <a href="https://stackoverflow.com/a/25911596/5853218">here</a> that deals with why one would want to use <code>reserved</code> memory as opposed to <code>committed</code> . It involves storing continuously expanding data - which is actually the stack model described above - and having specific absolute address ranges available when needed (although I'm not sure why one would want to do that within a process).</p>
  
  <p>Ok, what am I actually asking ?</p>
  
  <ol>
  <li>What would be a good analogy for the <code>reserved</code>/<code>committed</code> concept ?</li>
  <li>Any other reason aside those depicted above that would mandate the
  use of <code>reserved</code> memory ? Are there any interesting use cases when
  resorting to <code>reserved</code> memory is a smart move ?</li>
  </ol>