Is virtual memory related to virtual address space of a process?

Question

I have understood that Paging is a memory management technique which allows computer to bring data from secondary storage to main memory for executing process. It gives an impression to process that it has a large contiguous address space available to it (virtual address space). Page table maps virtual addresses of a process to physical address. Virtual addresses are the address that CPU uses. When need to access memory, physical address(actual address in RAM) corresponding to virtual address is obtained from page table using translation process. And concept of Virtual memory – when CPU needs memory more than the physical memory present, OS uses some part of secondary storage as RAM.

I get confused when I try to relate these two concepts. My question is - is virtual memory related to virtual address space of a process. Is virtual address space of a process actually present in virtual memory? But how is it possible since virtual memory is actually part of secondary storage. OR virtual address space of process is located in RAM? Does both the Virtual and Physical address space of a process present in RAM? Kindly clarify.

Answer 1

Virtual memory and paging should not be confused with the page file (also called the swap file).
The two concepts are indeed related, but still different.

Virtual memory refers to the virtual address space of a process: each process "thinks" it has a dedicated 32-bit (or 64-bit) address space, without actually doing so -- it might be that some pages don't actually exist in memory, or might exist at a different physical address, but the process doesn't care.

The method by which this is implemented is called paging: Whenever a process accesses memory, the Memory Management Unit translates the virtual address by looking up the physical page of RAM corresponding to the virtual page of memory. (A page is a larger unit of memory management, often 4KiB big). If no mapping exists, it triggers a page fault, to let the operating system know.

At this point, the operating system decides what happens next. It could terminate the program, it could generate the data randomly (!), or it could store or retrieve it from a page file (or swap file) on another storage device. But at this point, the hardware doesn't care what happens -- the operating system could do whatever it likes when handling the request.

So, virtual memory and the page file are not inherently related, but they just happen to come hand-in-hand in typical situations.

Answer 2

Let's take 32-bit x86 CPUs as an example, simplifying a bit for illustration. Some of the below is a little inaccurate on purpose to deliver the concept.

The instructions that let you load and store memory will take 32-bit arguments. So you have a "32 bit address" space. This means you can "talk to" 4Gbytes worth of RAM or whatever else happens to be there.

Virtual memory lets us map one address (a logical or virtual address) to another address (the physical, actual address). The default state is "identity mapped" where each logical address is set to its virtual address. Mapping happens on a 4KByte "page" level.

You have 2 levels of execution - user mode and kernel mode. Kernel mode needs to be identity mapped because it manages the system and other processes.

In user mode, the kernel maps memory where RAM starts at address 0 and it can only go as high as the amount of memory allocated to it. The kernel controls the memory mapping of all processes and manages what memory is free and in use. The kernel can pick free 4K byte pages from anywhere and arrange them so they look continuous to the user mode process.

The mapping mechanism can cause a "page fault" if the user mode page accesses an address that has an invalid page. If the user mode application tries to access more memory than it has, it will hit "bad" pages and trip a kernel exception. Then the kernel will kill it with a "Segmentation fault" error. Kernel APIs allow the application to ask for more memory - the kernel will then map it some free memory if possible, and release it when it's done.

So while you have a 32-bit address space you can't just use all addresses willy-nilly under a user process unless something is mapped there.

Now - if a process is dormant, the kernel may purposefully mark some pages as "bad" if it determines those pages haven't been accessed in a while, and write them to disk. When the process wakes up, it will try to access these bad pages and trip a kernel exception. Instead of "segfaulting" the kernel will retrieve the pages from disk, stick them back in memory (possibly in a different physical spot but mapped to the process's same logical spot) and then resume the process. This is how a swap or page file fits into the mix.

Both modern Windows and Linux kernels provide a facility called mmap where this mechanism is used "on purpose" to allow a file to be accessed like it's part of memory. The user space process can pick an address to put it - and the kernel will respond to "faults" by loading in or writing the right parts of the file on the fly. It uses this paging mechanism to allow that. On 64-bit systems with a very wide address space, very large files can be accessed as though they were in memory, which simplifies some programs.