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?

Solution 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.

Solution 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.

Solution 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]

Solution 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.

Solution 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.

View more solutions

Comments

[Admin]

That's the old concept. The original motivation for virtual memory was a form of memory management to provide an address space larger than physical memory. But that was when memory was low-density and very expensive. Nowadays the primary reason for using virtual memory is for process security.

[Admin]

"Now how is it increasing the memory?". It doesn't. The application isn't aware of the system's physical memory it's only aware of the virtual memory which is the reason when an application complains about not having enough memory it's talking about virtual memory and not physical memory

[Admin]

Keep in mind that virtual memory systems are pretty smart. If n processes have the same read-only page, all n processes can use the same one page of physical memory.

[Admin]

Don't think of virtual memory as fooling anything. Memory is the abstract ability to store and retrieve data. Virtual memory provides an implementation for that abstraction. That some part of that abstraction is backed by RAM and some is backed by disk is an implementation detail of the abstraction.

[Admin]

Actually, the ability to store data may be missing, and this is one of the key elements in efficient memory use. Memory pages that are identical between address spaces, and are guaranteed to remain so, can be shared. In practice, this means code and constant data tables can be shared, because they're marked read-only.

[Admin]

Typically the hard drive. From a windows user non programming perspective.

[Admin]

You should see several topics which relate to the phrase "virtual memory" some though similarly named may be have no relation. User mode virtual memory, Paging, segmented memory mode, linear address, logical address, and physical address. As well as additional reading in PCI configuration and standard.

[Admin]

Think of it this way: Your "memory" is always on disk. The physical RAM is just yet another level of cache to speed access ;) -- Actually, the same holds for disk volumes: They are more ephemeral beings than you thought, they are just typically at least partially (think thin provision) stored on physical disk drive in order to fulfill the promise that their data should survive system outages

[Admin]

@HagenvonEitzen Not sure how memory is "always" on disk... aside from pages originally read from disk, unless a page is swapped out its contents may never be on disk, and this is especially true for pages which are pinned in memory e.g. due to being critical to kernel functionality.

[Admin]

@HagenvonEitzen Yeah, not really. When I boot my macOS (AKA OS X) machine, “Swap Used” is sitting at 0.0 MB— so none of my “memory” is on disk, since the data structures that make up the programs running have been initialized in-memory— some derived from on-disk sources, some derived from network activity, but most calculated on-the-fly (though with data layouts specified in the structs/classes compiled into the executables). I believe macOS also still supports root-owned-plist configuring that disables swap, though then things go awry pretty quick when the physical RAM is exhausted.

[Admin]

I read a nice blog post about this recently. jvns.ca/blog/2016/12/03/how-much-memory-is-my-process-using-

[Admin]

@SlippD.Thompson code and read-only data sections are backed by the executable file and can therefore be swapped out without writing to the swap file, and may not have been loaded into physical memory yet in the first place if they haven't been used.

[Admin]

@Random832 True true— so my “none” conclusion wasn't completely accurate. That said, for most executables the executable's assembly is rarely going more that 5% the size of the RAM usage, and the data section rarely more than 1% (you could have an app that makes extensive use of lookup tables and thus uses well more than 1%, but in most real-world apps we're talking KBs on the meg).

[tbodt]

it's sad we live in a world where each browser tab requires 1GB of memory

[Dmitry Grigoryev]

@tbodt I blame ancient Egyptians. If only they knew what they were doing by domesticating those pesky cats!

[100rabh]

Comments are not for extended discussion; this conversation has been moved to chat.

[Random832]

@tbodt It's a bit of an exaggeration too. My browser with 8 tabs open only takes 500MB of memory.

[Dmitry Grigoryev]

@Random832 Sure it's an exaggeration, though I'm not sure about the line between exaggeration and being future-proof. My first PC had 32 MB of RAM and I could easily open 8 tabs in Opera without noticeable swapping. Now it takes 500MB, so in another 20 years it might as well reach 8GB.

[cheems]

@DmitryGrigoryev I can confirm that now one chrome tab uses 800+ MB.