Memory Management issues make up a considerable portion of the support incidents that we handle. At some point during the support incident we invariably engage in a discussion of Memory Management, Memory Tuning, the use of the infamous /3GB switch and more. There's far too much information to compress into a single blog post, so think of this as the first part in a series. In this post we'll cover the basics of 32-bit Memory architecture and the difference between Kernel and User mode memory. So let's dive right in ...
Windows 32-bit Operating Systems implement a virtual memory system based on a flat 32-bit address space. 32-bits of address space translates into 4GB of virtual memory. A process can access up to 4GB of memory address space (using the /3GB switch changes this behavior - and we'll cover that in a later post).
You can't have a discussion of Memory Management basics, without distinguishing between Kernel-mode and User-mode memory. The system space (aka Kernel space) is the portion of the address space in which the OS and kernel-mode drivers reside. Only kernel-mode code can access this space. User-mode threads can access data only in the context of their own process. User-mode threads cannot access data within another processes space directly, nor can it access the system address space directly. Kernel-mode drivers are trusted by the OS and can access both kernel and user space. When a driver routine is called from a user thread, the thread's data remains in the user-mode space. However, the kernel-mode driver can access the user-mode data for the thread and access the kernel-mode space.
OK - so looking at the diagram above, we can see how the 4GB memory address space is divided. Windows allocates the lower half of the 4GB address space (from 0x00000000 to 0x7FFFFFFF) to processes for their own unique private storage, and reserves the other half (from 0x80000000 to 0xFFFFFFFF) for the Operating System's use. Virtual memory provides a view of memory that does not necessarily correspond to the physical layout of memory.
This is usually the point in the discussion where the majority of folks start getting confused and their eyes start to glaze over. In simplistic terms, the memory manager translates the virtual memory addresses into physical addresses where the data is stored. Every page in virtual memory is listed in a page table which in turn identifies the correct physical page. The system and CPU use the information from the virtual address to find the correct page table entry for a specific page.
So, looking at the diagram on the left, we can see that a virtual address points to a specific location on a virtual page. The virtual address contains a byte offset and several index values that are used to locate the page table entry that maps the virtual page into physical memory. After the memory manager finds the page table entry, it uses the offset to find a byte in physical memory - identified by a physical address.