Learning about RAM, virtual memory etc

Lets back up a little bit... you're mixing up a few things.

First, lets talk about an IDEAL, theoretical concept of how virtual/physical RAM works, in simple terms:

1) The computer has a certain fixed amount of physical memory. It is addressable by the hardware (lets say for example that the addresses go from 0 to 65535)

2) Each applications does not get to actually the phyiscal memory directly and it never knows what the real physical addresses is. Instead, they get a "virtual" address. When they attempt to access memory, the virtual address is "automagically" converted into the physical address, and this is used to access the memory. The component that performs that conversion is called the "Memory Management Unit", or the MMU.

This process has NOTHING to do with pagefiles, swapping, etc. We're just talking about regular RAM so far.

So for example, lets say we have Excel, Word, and Firefox open. Each program would be assigned memory:

        Excel
             (assigned memory addresses 0 to 500)
        Word
             (assigned memory addresses 0 to 500)
        Firefox
             (assigned memory addresses 0 to 500)

In reality, these three blocks of memory could be stored in addresses 605-1105, 102-602, and  1423-1923 respectively.

Why is this useful?

Because it means the applications does not need not know how or where the memory is stored. This provides the operating system and hardware with many conveniences:

- Applications can be prevented from reading or modifying each other's memory, essentially isolating them from each other. Blocks of memory can be reserved and cannot be touched by any application

- Applications can access memory in a sequential virtual block, even if the physical storage of that memory is fragmented and scattered across the actual physical memory. The application programmer need not concern themselves with it.

- The system can rearrange memory or move things around, and the application doesn't need to know about it

- A 32-bit application running on a 64-bit OS can be given a block of memory that is physically located in an upper space >4GB, in a location that the application would not normally be able to address

You can see how the "virtual" memory system, in an ideal world, has many advantages, but has NOTHING to do with pagefiles, swap files etc.

In other contexts, "virtual" memory can refer to the Windows operating system's process of storing application memory on a file in the hard drive.

The specifics and caveats vary from one operating system and architecture to another but are secondary to the core concept of virtual/physical memory allocation.

The next core concept to cover is "swap files". Windows also refers to this as "virtual memory", but it is a different concept than what I talked about above. Really, it just refers to the technique used by the operating system to utilize hard disk space as additional memory.

The operating system allocates space on the hard drive for the purpose of storing the pagefile. When the operating system detects that it is running short on physical memory, it offloads some of the physical memory into the pagefile in order to make space.

If an application ever attempts to access a block of memory, and that memory has been offloaded into the pagefile, the application must WAIT for the operating system to clear some space in physical memory and load it back in from the hard disk. That is to say, neither applications nor the OS ever actually reads from the pagefile directly, rather memory is "swapped" in and out of the pagefile into RAM whenever an application needs it.

For this reason, the OS tries to put the oldest, most rarely used memory into the pagefile in order to make space in RAM for the more frequently accessed blocks. This helps speed up the computer. There are various tricks the OS employs in order to decide what goes into the pagefile and when.

In particular, the OS will preemptively "swap" and minimized application into the pagefile to make room for the currently active application, so that if it needs to allocate more memory it is immediately available.

This memory swapping and paging is done entirely in software - the hardware is not responsible for these actions. So the performance and behavior of pagefiles and swap files varies greatly from one OS (e.g. Windows) to another (e.g. Linux).

Whoops I need to correct myself.

The operating system imposes several limitations on how much memory each process is allowed to allocate, and how much memory TOTAL the OS will allocate for processes and for itself.

For all intents and purposes you can assume these limitations are arbitrary and made either for technical reasons, or for business reasons.

The core concepts of memory allocation I talked about above are still true, but the specific limitations and caveats to that ideal and simplified explanation are described in lots of depth in the link I gave above:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

Excellent!! Thank you for the very comprehensive reply, I really appreciate it.

One thing I am still not sure upon...

Let's say I have four different processes running on my x86 Windows 2008 server.

Are you saying that there is one entity known as the virtual memory that can address up to 4GB. Each process can use different blocks of this virtual memory, but overall these processes can only use UP TO 2GB of virtual memory between them? It's not the case that each process itself can use up to 2GB of virtual memory?

In which case, if the above former statemement is correct, if this server had 4GB RAM installed, then no swapping would occur? Because since the processes can only use up to 2GB RAM collectively, and the rest is reserved for the OS, when would we ever exceed 4GB of virtual memory used?

Anyone know the answer to my last point?