Will Microsoft Windows 10 overcommit memory?

Question

Linux OS:es will typically allow overcommit of memory. For example a process can allocate 100GB memory, even though the machine only has 8GB physical memory and no swap.

As long as all the allocated memory isn't actually used, the process will work. If the program tries to use it all, the OOM-killer will kill processes to free up memory.

How does this work in Windows? Will Windows refuse to give processes virtual memory unless it can guarantee that this memory can be backed by actual memory (physical RAM or swap)?

Answer 1

Answering my own question, as no one else has.

It seems to be the case that Windows will NOT overcommit memory. This is actually a big difference compared to Linux.

Windows will allow a program to allocate more (virtual) memory than there is RAM on the machine, but ONLY if there is enough free disk space to be able to back the virtual memory requested by the program by disk if necessary.

Answer 2

Not sure if this is relevant, but certain applications will have their memory use limited, like Powershell, and throw these errors unless memory allocation settings are changed. Or you run commands through a separate application, like Spyder.

Answer 3

Windows does overommit stacks. You can easily create a number of threads with stack space far beyond RAM + swap. The following C++20 program shows the page attributes of a one MB stack:

#include <Windows.h>
#include <iostream>

using namespace std;

int main( int argc, char **argv )
{
    auto stackThread = []( LPVOID lpvThreadParam ) -> DWORD
    {
        ULONG_PTR stackTop, stackBottom;
        GetCurrentThreadStackLimits( &stackBottom, &stackTop );
        char const
            *pStackTop = (char *)stackTop,
            *pStackBottom = (char *)stackBottom;
        SYSTEM_INFO si;
        GetSystemInfo( &si );
        MEMORY_BASIC_INFORMATION mbi;
        auto query = [&]( char const *p ) -> char const *
        {
            if( VirtualQuery( p, &mbi, sizeof mbi ) != sizeof mbi )
                ExitProcess( EXIT_FAILURE );
            return (char *)mbi.AllocationBase;
        };
        char const *base = query( pStackBottom ), *p;
        do
        {
            cout << mbi.RegionSize / si.dwPageSize << ": ";
            unsigned n = 0;
            auto append = [&]<typename ... T>( T &&... values ) { cout << (", " + !n++); ((cout << values), ...); };
            if( mbi.State != MEM_FREE )
                if( mbi.State == MEM_COMMIT )
                    append( "comitted" );
                else if( mbi.State == MEM_RESERVE )
                    append( "reserved" );
                else
                    append( "S: 0x", hex, mbi.State );
            if( !mbi.Protect )
                append( "unacessible" );
            else if( mbi.Protect & PAGE_GUARD )
                append( "guard page" );
            else if( mbi.Protect == PAGE_READWRITE )
                append( "read-write" );
            else
                append( "P: 0x", hex, mbi.Protect );
            cout << endl;
            p = (char *)mbi.BaseAddress + mbi.RegionSize;
        } while( query( p ) == base && mbi.BaseAddress < pStackTop );
        return 123;
    };
    HANDLE hThread = CreateThread( nullptr, 0x100000, stackThread, nullptr, STACK_SIZE_PARAM_IS_A_RESERVATION, nullptr);
    WaitForSingleObject( hThread, INFINITE );
    CloseHandle( hThread );
    return 0;
}

This are the stack attributes shown on my computer:

251:  reserved, unacessible
2:  comitted, guard page
3:  comitted, read-write

As you can see most of the stack is initially uncommitted.