Virtual memory

From Citizendium
Jump to navigation Jump to search
This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Virtual memory is an important concept in computer science that lets a program use more random access memory (RAM) 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.

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 commonplace in personal computers. Without virtual memory, 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 in the physical memory; the burden on programmers for this extra design effort was high, and the pace of creating large programs was correspondingly very slow.

There are two aspects to virtual memory. The first is the amount of real, physical memory that is present in the machine. The second is the (much larger) virtual address space, which must be mapped at runtime onto a portion of the physical memory. Some parts of running programs are stored on an 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 addresses and virtual memory addresses, and then efficiently move chunks 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. 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]. The kind of operating system interrupt that occurs when information needs to be 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.

The swap file

Most computers which implement virtual memory have a special file (or partition, in the case of *nix systems) on their disk called a swap file, or sometimes a paging file. This is the file into which unneeded parts of running programs are written. Since the operating system owns and uses this file, it may not always be visible to users. Some operating systems, such as Windows, allow the swap file to be distributed across multiple disks provided that additional fixed drive partitions are available. The swap file, whose contents are not easy to read as they are in binary format, is one of the places where an expert on computer forensics might look for exidence of how a machine has been being used. Even if programs are no longer running, the information paged into the swap file while the program formerly ran may still be legible in the available parts of the swap file.

What can go wrong?

Situations can arise where the computer ends up using a majority of its computing power in paging, constantly 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, either by using the Task Manager (in Windows), or using "kill" in *nix-based systems. Long periods of thrashing may also reduce the life span of the hard drive, resulting in premature failure or file corruption.

On Microsoft Windows computers, the operating system may increase the size of the swap file as needed, given enough available disk space. Over time, growing and shrinking of the swap file may cause it (and other files) to become fragmented (stored in discrete chunks in various different parts of the disk). File fragmentation can slow down a machine, and this can be prevented by defragmenting the disk and then telling Windows to use a fixed size swap file (but, you need to choose a sufficiently large size for any circumstance). That way, when few programs are running, much of the swap file may be unused but remains reserved in case it is needed, and the disk will not become fragmented due to swapping.

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 speed, 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.

Marketplace 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, to the lay purchaser, 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).

References

  1. 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)
  2. W. S. Davies and T. M. Rajkumar. Operating Systems: A systematic view. Pearson Education, 2005. Page 127
  3. Andrew S. Tannenbaum. Modern Operating Systems. Prentice-Hall 2001. Page 202-203