What are the consequences of reserving a huge amount of memory, most of which is never committed?


A customer had an idea of solving a program by reserving a huge amount of memory with Virtual­Alloc, and then committing only the parts that are actually needed. And by huge, they're talking about 100GB. (Obviously, on a 64-bit machine.) Is this okay, or is it a bad idea, or is it a terrible idea?

Starting in Windows 8.1 and Windows Server 2012 R2, it's cheap to reserve a lot of virtual address space. No major memory allocation or other charges occur until you start committing pages, in which case the memory requirements are proportional to the amount of address space you commit, rather than the amount of address space you reserve.

Things were different in earlier versions of Windows. Back then, reserving address space still incurs a cost for creating the page tables required to map the reserved region. In the above example, a 100GB reservation would cost 200MB of memory for the page tables. Depending on the nature of the system you intend to run the program on, this may be an acceptable cost.

Comments (9)
  1. — "...solving a program..."
    Do you mean he was in some sort of development competition?

    1. Brian_EE says:

      I am sure he meant "...solving a problem..."

      But since problem and program are synonyms, who's going to complain about word choice?

  2. NTAuthority says:

    Of course, this change correlates nicely with Control Flow Guard, which reserves a few *TB* of address space for a bitmask of every possible code target.

  3. pm100 says:

    could you do another post going into details as to why it used to be expensive and now isnt.

    1. I thought I explained it in the last paragraph. The page tables for the reserved pages used to be created at reservation time. Now they are created on demand. (In other words, instead of creating a page table full of "reserved" entries, you can create a page directory entry that marks the entire page table as "reserved". This saves you a page table.)

  4. henke37 says:

    Another fun thing you can do with loads of reservated space is creating objects that will not reuse addresses. Must make debugging simpler and exploiting annoying.

  5. Josh B says:

    I guess this makes Large Pages rather less important now, especially if you don't need them all. That's a relief, since it took elevated permissions and they couldn't be paged out to disk.

    1. Um, you can't reserve large pages in the first place (you can only commit them), so this has no effect on large pages.

    2. Patrick Star says:

      Large pages are still very much relevant. The (big) reason for using large pages is the limited size of TLBs. Once you start accessing more memory than (page size) * (number of TLB entries) in a "random" way (databases being the prime example of this), the poor CPU will need to start walking page tables, which are stored in RAM. So one memory access turns into several, potentially causing very severe performance issues.
      The change this article refers to only applies before you actually start using most of the reserved memory.

Comments are closed.

Skip to main content