Note that "virtual memory" is more than just "using disk space to extend physical memory size"
Virtual memory is a layer of abstraction provided to each process. The computer has, say, 2GB of physical RAM, addressed from 0 to 2G. A process might see an address space of 4GB, which it has entirely to itself. The mapping from virtual addresses to physical addresses is handled by a memory management unit, which is managed by the operating system. Typically this is done in 4KB "pages".
This gives several features:
- A process can not see memory in other processes (unless the OS wants it to!)
- Memory at a given virtual address may not be located at the same physical address
- Memory at a virtual address can be "paged out" to disk, and then "paged in" when it is accessed again.
Your textbook defines virtual memory (incorrectly) as just #3.
Even without any swapping, you particularly need to be aware of virtual memory if you write a device driver for a device which does DMA (direct memory access). Your driver code runs on the CPU, which means its memory accesses are through the MMU (virtual). The device probably does not go through the MMU, so it sees raw physical addresses. So as a driver writer you need to ensure:
- Any raw memory addresses you pass to the hardware are physical, not virtual.
- Any large (multi page) blocks of memory you send are physically contiguous. An 8K array might be virtually contiguous (through the MMU) but two physically separate pages. If you tell the device to write 8K of data to the physical address corresponding to the start of that array, it will write the first 4K where you expect, but the second 4K will corrupt some memory somewhere. :-(
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.
Best Answer
It is not increasing physical memory at all. Its purpose is something else entirely. What it can do is make available other backing stores that allow programs to use more memory than is physically available.
Virtual memory is used to separate and isolate processes from each other and also allow memory access to be diverted to alternative locations.
Virtual memory allows the system to give every process its own memory space isolated from other processes. With programs effectively operating in their own space it gives them full access to the entire address space rather than having to work around other programs which might also need to use the "same" addresses. This has the side effect of increasing reliability and security as processes cannot easily interfere with each other.
The virtual memory space of an application is built up as needed. An application looks (to itself) to be in a single contiguous block of memory but could actually be completely scattered across physical memory.
Virtual memory also allows memory accesses to be trapped and diverted which allows us to use features like a swap file. What this means is that we can push parts of memory that haven't recently been used out to disk and set up a pointer that says "this block of memory is in file x at location y" and then we can free up the physical memory area for use by another application. When an application needs that memory it can be read back from disk, placed at some location of physical RAM (potentially different from where it was before) and mapped back into the same location of virtual memory as it was previously.
In the same way as the page file is used virtual memory can also allow the operating system to do what is effectively "lazy" loading of shared libraries for a program. When the main program tells the operating system that it wants to use a particular library then the operating system can save time by checking the requirements for the library, allocating the space in the virtual memory area for the application, but rather than load the entire library in it can defer loading pages of the library in from disk until they are actually needed. In this way the only parts of the library that get loaded into RAM are the parts that are actually used by the program, parts that are never used never get loaded and so don't waste RAM.
Using these techniques we improve the stability of the system and allow more processes to run in a confined space without them unduly affecting each other. It does not "increase memory", but instead allows us to more effectively use what we have.
The swap file is enabled by virtual memory systems, but in the past was confused as being the virtual memory.