Friday, 20 August 2004

Heap in NT can use a lot of virtual addresses

Raymond Chen has recently been writing about the /3GB switch, virtual memory and physical memory. If you don't understand what virtual memory is, go there now.

Back? Good. I want to talk about a situation where you might run out of virtual address space a long time before you run out of RAM. Exchange's documentation recommends that if you have more than 1GB of memory you should enable the /3GB switch. As Raymond notes, basically the STORE.EXE process, due to inefficiencies, uses more virtual address space than actual RAM.

In a comment on Carmen Crincoli's blog, Larry Osterman mentioned that the NT heap manager expands the virtual address space for a heap in powers of two. Note that this doesn't mean the physical memory used goes up like that - Windows will only allocate physical memory to a process on demand and only up to its maximum working set size, unless memory is more abundant than that. However, you can get into a situation where your heap's virtual address space resembles a Swiss cheese - there's plenty of free memory, but it's all in small free blocks. To allocate a large block, Windows has to expand the heap's address space, which it does by allocating a new chunk of address space twice the current size of the heap. It must be possible for this to be multiple chunks - this algorithm would start running into problems at around 512MB or so of virtual addresses if it allocated a single contiguous block...

What's the initial size of the heap? It's marked in the executable's header - the default generated by the MS linker is 1MB.

Note that Windows supports multiple heaps. The recommended practice is actually to have one heap for each distinct type (or at least size) of object; I think I've written about this before. Unfortunately many APIs don't give you a choice where something is allocated - they just dump it on the default heap.

[Edit: I knew something was bothering me about the original title - I confused VM with virtual addresses - as we know, they're not the same thing...]

No comments: