How is virtual memory actually increasing the memory space?

Question

I understand that virtual memory fools the program by displaying more memory than is actually available.

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Answer 1

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.

Answer 2

Layman's explanation

The system will have to map each virtual address to physical address when that memory is used, but not all memory is used at the same time. For example, suppose you have 20 tabs in your browser, each taking 1GB of memory. In the OS without virtual memory support, you would need 20GB of RAM for this to work. The trick is, you don't browse all 20 tabs at the same time, so the OS with virtual memory will enable you to use your browser like that with just a couple of GB of RAM, swapping inactive tabs to disk.

More complex aspects

Virtual memory isn't used exclusively for swapping. It's main purpose is actually to avoid RAM fragmentation, which is a big problem on systems without virtual memory management: you may well have 1GB of RAM free, but if it comes in chunks of 10MB, an application requesting 100MB will not be able to work.

Over time, virtual memory found even more uses, notably random file access: many applications like databases will become painfully slow if they are forced to read files sequentially, and work much faster if the OS lets them pretend the whole file is located in (virtual) memory and optimize disk IO and caching based on access patterns.

Answer 3

Virtual memory doesn't increase memory, in the sense of actually adding more main-memory hardware. But it CAN increase the range of usable addresses. So one could have a running program consisting of a code segment and a data (stack & heap) segment, and both of these could occupy a range of virtual addresses larger than the range of physical addresses provided by the physically-real storage space of the machine. The trick is that only a small fraction of those virtual addresses are backed by physical main-memory at any moment [but everything is ultimately backed by disk storage]. This works because of the phenomenon of locality of reference: At any moment, only the instructions in one or more small contiguous sections of the program segment are being executed, and only data in one or more small contiguous sections of the data segment are being operated upon [of course the behavior is actually more complex, but it does follow this pattern for a large fraction of the time]

Answer 4

I understand that virtual memory fools the program by displaying more memory than is actually available.

The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory.
Software could utilize the full address space of the CPU (e.g. 2^32 address space) while the actual installed physical memory was only a fraction of that number.
Large programs could be portable among computers that used virtual memory without imposing huge (installed) memory requirements.
This use of virtual memory was back in the day of mainframe computers and ferrite core memory (which was low-density physically and expensive).

But ultimately it has to map the logical address to the actually physical address. Now how is it increasing the memory?

Virtual memory has evolved from just a technique to provide more address space for the program.
Virtual memory is a key component in providing security to each process in modern operating systems, so that a process cannot interfere with another process, nor be compromised by another process.
But multiprocessing (do not confuse with multiprocessors) with virtual memory still does provide more apparent memory for the system than physical memory.

Each created process is provided with its own virtual address space, i.e. its own virtual memory.
The amount of physical memory that is actually used (and mapped to the virtual memory) to each process is dynamic. Typically only the virtual memory that contains the code (aka text) and data pages/segments to perform the execution of the process is mapped to physical memory (aka resident in memory).

Nonessential code (because it's not currently executed) and data (because it's not being referenced/processed) does not have to be memory resident all the time. The code and/or data pages/segments can be "swapped out" to the backing store (e.g. swap space or page file on a HDD or SSD), and later "swapped (back) in" as needed (aka "on demand").

Virtual memory facilitates the efficient usage of the finite physical memory among numerous processes, each with its own protected virtual address space. The sum of these virtual memories would typically be larger than the installed physical memory.
The "increased memory" is now from the system perspective, and not just the program perspective.

Answer 5

Virtual memory increases the amount of data a program can address. From a software point of view, we (generally) don't care where they data is stored. It could be stored in physical DRAM memory, it could be stored on a flash drive plugged into the machine, or it could even be stored on a spinning platter. What the software cares is that, when it asks to access that data, it succeeds.

In practice, we also want programs to run fast. For speed considerations, we do care where the data is. We want the data we are accessing most often to be stored in hardware which permits the fastest access. Our programs would like to run entirely out of DRAM. However, we often don't have enough DRAM to do this. Virtual memory is a solution.

With virtual memory, the operating system "pages" out data which has not been used in a while, storing it on a hard disk. This is still accessible, just slow. If the program requests data that's on the hard-disk, the operating system has to take the time to read the data off of the disk, and move it back into DRAM.

In theory, it could just read the data directly off of the disk. However, there's reasons it isn't done that way. The programs don't want to have to be aware of all of these complications. We can and do write software which intelligently puts data on disk (it's called caching). However, it takes a lot of extra work. The fastest we can do it in code is:

if data is not in memory
    read data from disk into memory
operate on data

An astute reader will notice that, even if the data is in memory, we had to have a conditional to check whether it is there. This is much slower than just operating in memory directly!

Virtual memory solves this problem by doing the check in hardware on the CPU. The CPU is in a position to do this virtual memory operation extremely quickly because it can dedicate hardware to it. Any attempt to do this in software alone must use the general purpose parts of the CPU, which are naturally slower than dedicated transistors would be.

This leads to why we always page the data back into memory rather than just reading it from disk and leaving it at that. We break the memory up into "pages," each of which is marked as either present or not present in memory. The operating system maintains this table in a format which is convenient for the CPU to use directly. Whenever a program accesses data that is present, the hardware on the CPU gives them access to the data in DRAM directly. When the data is not present, a "page fault" is issued, telling the operating system to go load that page off of the disk to some physical page of memory and the update the table to point the CPU at this new physical page.

The key to this whole problem is to minimize its usage. In practice, we find that operating systems are very good at choosing what data to keep in memory and what data to page out to disk, so the vast majority of memory accesses occur without ever causing a page fault.

Answer 6

It does so by making map entries temporary.

When a program accesses a logical address, the CPU looks in the map for a corresponding physical address. If it's found, the memory access proceeds as expected; if it's not found then a physical address must be allocated and the content loaded from some other storage - the "swap space". If every physical address has already been allocated to some logical address, then some logical addresses must be "swapped out" (their content saved back to the swap space) to make physical addresses available.

The maximum allocated memory is the size of the swap space, which can be much larger than the installed memory. It might be helpful to think of the swap space as the "real" memory, and of RAM as a high-speed cache for the swap space.

(This is far from a thorough description, it's intended to answer the immediate question without getting into relevant-but-unnecessary detail.)

Answer 7

The basic concept relies on the fact that a modern CPU can manage translation tables keeping track of "what address ranges has a certain process been allocated to use, and which physical addresses (think A00..Axx lines on a memory bus), IF ANY, currently are used to actually store the data. "IF ANY" because "none at all" is a possible and acceptable state: In this case, an error condition (a so called "page fault") will be raised on a hardware level - and this error will trigger an OS-level handler that can eg load memory contents that have been written to a swap file back into any free location in physical memory (in case of a read) or find an actual location to put stuff (in case of a write), update the aforementioned translation table, and only THEN hand control back to the process that attempted to access that memory.. and which will be none the wiser of what happened.

Answer 8

Virtual memory:

1) allows a large virtual address space to be mapped to a smaller amount of physical memory, with excess "swapped out" to disk, or SSD, or prospectively to NVRAM and other devices.

2) allows a larger virtual address space (e.g. 64-bits) to be mapped to a smaller physical address space (e.g. 32 or 64 bits)

3) allows a smaller virtual address space (e.g. 32 bits) to be mapped to a larger physical address space (e.g. 40 bits), and thereby allows older applications to take advantage of more physical DRAM.

4) allows physical memory that us fragmented and non-contiguous in the physical address space to be rendered contiguous in the virtual address space.

5) allows processes to be given their own virtual address spaces, and hence be isolated from each other.

6) allows different virtual addresses that happen to share the same data values to allocated a single physical page.

This can happen within a single process or OS - most BSD UNIX derived OSes have a single read-only page of zeroes, that can be mapped into any zero-filled virtual page, typically COW (Copy On Write - read only zeros, writes trapped and page unshared and made writeable).

It can happen between processes - e.g. UNIX fork() creates child processes that share almost all virtual memory in a COW manner.

It can happen between OSes - e.g. Guest OSes on a virtual machine host can have pages deduplicated, shared COW, etc. (Some recent security attacks have taken advantage of this.)

7) virtual memory can allow parts of the virtual address space to be mapped to files, or to memory mapped on other processors, whether in the same multiprocessor system, or across the Internet.