Nowadays, computers have so much memory that running out of RAM is rarely the cause for an “out of memory” error.<\/p>\n
Actually, let’s try that again. For over a decade, hard drive have been so large<\/a> (and cheap<\/a>) that running out of swap space is rarely the cause for an “out of memory” error. <\/p>\n In user-mode, the term memory<\/i> refers to virtual memory, not physical RAM chips<\/a>. The amount of physical RAM doesn’t affect how much memory a user-mode application can allocate; it’s all about commit and swap space.¹ But swap space is disk space, and that is in the hundreds of gigabytes for hard drives. (Significantly less for SSDs, but even in that case, it’s far more than 4GB<\/a>.) <\/p>\n The limiting factor these days is address space. <\/p>\n Each thread’s stack takes a megabyte, and if you’re creating a lot of threads, that can add up to a lot of address space consumed just for stacks. And then you have to include the address space for the DLLs you’ve loaded (which quickly adds up). And then there’s the address space for all the memory you allocated. (Even if you don’t end up using it, it still occupies address space until you free it.) <\/p>\n Typically, when you get an This is one of the main benefits of moving to 64-bit computing. It’s not that you actually are going to use or need all that memory. But it relieves pressure on the address space: The user-mode address space in 64-bit Windows is eight terabytes<\/i>. <\/p>\n When the day comes that eight terabytes is not enough, we at least won’t have to redesign the application model to expand the address space. The current x86-64 hardware has support for address spaces of up to 256TB, and the theoretical address space for a 64-bit processor is sixteen exabytes. <\/p>\n ¹ Of course, physical RAM is a factor if the application is explicitly allocating physical memory, but that’s the exception rather than the rule. <\/p>\nERROR_OUT_OF_MEMORY<\/code> error, the problem isn’t physical memory or virtual memory. It’s address space. <\/p>\n