Virtual memory
Virtual memory is an important concept in computer science that lets a program use more memory than is physically available for it. In a computer having virtual memory, the operating system keeps the needed parts of running programs in main memory, and puts the parts that are not currently used on the disk. The parts on the disk will then be swapped into memory as needed. The concept of virtual memory was first described by Fotheringham in 1961[1]. The mechanisms for virtual memory swapping are, for the most part, transparent to users, who may use the computer as if it really had the larger amount of virtual memory rather than the smaller amount of physical memory.
There are two components in virtual memory. The first part is exactly equal to the amount of real memory, and is physically stored in in real memory. The second part is the space having addresses above the real memory. This part is stored on a external paging device, usually a hard disk.[2]. A special part of a computer's hardware, usually called the memory management unit, helps the operating system perform the mapping between physical memory and virtual memory, and then efficiently move hunks of programs back on forth between physical memory and disk as needed. Implementations of virtual memory are complex and result from an enormous amount of learning and specialization in the field of computer architecture and hardware and operating systems design.
Paging
Most virtual memory systems use a technique called paging. The virtual address space is divided into units called pages, and the corresponding units in physical memory are called page frames. It is most common to use pages of a fixed size. Transfers between main memory and the external paging device are usually in units of a fixed-size page. A virtual address is mapped to a physical address by a Memory Management Unit (MMU)[3]. When pages are pulled from swap space back into main memory this is called a 'page fault.' It is common for modern computers to use fixed-size pages because this makes certain aspects of page management simpler to design, but variable-sized paging implementations do exist.
Designers of computer operating system have also found ways to other ways to take advantage of virtual memory paging. For example, some computers can restrict certain pages to be read-only to programmers; read-only pages in memory are used to store program code (so it cannot be modified by viruses, for example) and constant values that a programmer is not allowed to change. Any attempt by a programmer to write into a restricted page in memory will result in a "page fault" or "segmentation" error. This topic formerly was of interest only to operating system developers, but in today's networked environment full of computing attacks that try to take over programs on computers through programmer errors, these topics have gained in importance in studying computer security issues.
What can go wrong?
Situations can arise where the computer ends up using a majority of its computing power in moving hunks of programs and data onto disk and back into memory. This situation is called thrashing, and the only way out of it is to cause some programs to stop running (usually by rebooting the computer).
Virtual memory and caching systems
Virtual memory works with mechanisms that are similar to cache memory, but for very different reasons. Caching also uses a paging type mechanism across two or more banks of increasingly slow physical memory. Whereas virtual memory's goal is to increase apparent memory size, caching's goal is to increase apparent computer speed by keeping parts of programs that are running in faster memory, and less often used parts in slower physical memory.
There are complex interdependencies between virtual memory implementations and cache memory implementations. These implementations may contribute more to the overall throughput of a computer than the actual processor speeed, because disk operations are much slower than computations being done in the processer (by an order of magnitude). As a rule of thumb, this means that a user may get a faster computer, in some cases, simply by having more memory (and especially cache memory) than by installing a faster processor.
Cost issues
A substantial portion of the design effort in specifying computer instruction set architectures, and in implementing hardware that runs them, has to be devoted to these complex memory management issues. Likewise, a substantial portion of computer operating system design effort must necessarily go into the virtual memory and cache related operations.
The specifications advertised on commercial computers usually place a higher emphasis on processor speed than memory, and often, the a lay user, the cache memory sizes and other related specifications are not even advertised, which makes sense because they are so little understood by people in general. In fact, manufacturers may be rather protective or secretive about the exact ways in which virtual memory and caching are done on a specific computer, because this is one of the ways in which a computer can appear to run faster than other computers (hence, the information may be treated as proprietary in the marketplace).
History and importance
The development of good virtual memory and cache memory implementations may be regarded as seminal in the growth of computer technology. By the 1990's, virtual memory had become commomplace in personal computers. But before that, computers were limited in the size of programs they could run. Very large programs had to be broken into discrete chunks that could execute individually from other parts; the burden on programmers for this extra design effort was high, and the pace of creating large programs was correspondly very slow.
References
- ↑ John Fotheringham. Dynamic storage allocation in the Atlas computer, including an automatic use of a backing store, in Communications of the ACM, Volume 4 , Issue 10 (October 1961). Pages: 435 - 436 (ACM)
- ↑ W. S. Davies and T. M. Rajkumar. Operating Systems: A systematic view. Pearson Education, 2005. Page 127
- ↑ Andrew S. Tannenbaum. Modern Operating Systems. Prentice-Hall 2001. Page 202-203