Talk:Virtual memory

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
WikiProject Guild of Copy Editors
WikiProject icon A version of this article was copy edited by a member of the Guild of Copy Editors. The Guild welcomes all editors with a good grasp of English and Wikipedia's policies and guidelines to help in the drive to improve articles. Visit our project page if you're interested in joining! If you have questions, please direct them to our talk page.


As noted, paging/swapping is not a required characteristic of virtual memory, so I moved the section on Thrashing to the Paging article. It also needs some cleanup. Guy Harris (talk) 09:09, 5 January 2008 (UTC)

I agree about 75% - the text you moved was too long and technical for Virtual memory. But the article does need to mention thrashing and say "for more info see ...": it's a well-know problem of virtual memory systems and, if we don't mention it, someone may be tempted to add another excessive explanation. I'm inserting a simple explanation with "for more info see ...". Philcha (talk) 12:40, 5 January 2008 (UTC)

Top image[edit]

What's the reason for trying to replace a 4 KB .png file with a 17 KB .svg image? Philcha (talk) 14:31, 29 May 2008 (UTC)

I believe it is because SVG images are scalable (they don't pixelate when the size is increased) so they are preferred over PNG. Rilak (talk) 07:13, 30 May 2008 (UTC)
Printed version, huh. Poor amazonian trees. --Kubanczyk (talk) 07:55, 30 May 2008 (UTC)

Virtual memory confusion[edit]

Having read the article for the first time, and the discussions here, it seems to me to be a total confusion about what virtual memory is. First of all, let's separate the subject of demand paging from virtual memory. Demand paging is a different topic. Second, virtual memory is not about fooling the program into believing it has more memory that physically exists in the machine, although that can be one side effect of the whole deal.

What virtual memory is all about is to fool a program that it is alone in memory space, and that the whole memory space is exclusively for use by that program. Memory space starts at address 0 (well, it can be elsewhere as well, if it makes more sense), continues with or without holes in it, but the memory is not shared with other uses/users. A program can't tell that it's virtual memory. It looks just like physical memory to it, and the same exclusive view is given to all programs that might be running concurrently on the same computer. Thus, the same virtual address for different running programs can (and usually will) map to different physical addresses. So programs with different contexts can all refer to the same virtual address, but will be talking about different physical addresses. That's all there is to it. Or one program can refer to the same virtual address, but make that address refer to different physical addresses, if the program can manipulate the translation between virtual and physical addresses.

Now, to make a few things clear. A PDP-10 have a virtual memory system. So do a PDP-11, and a bunch of other computers, none which fulfills the definition that this article have made previously. If this article were to be taken at face value, Unix didn't have virtual memory until 4BSD.

Also, given the ideas that virtual memory is a way of fooling a program that it has more memory than physically exists, the PDP-11 is a fine example of where that is not true. The virtual address space is only 16 bits, while the physical address space of the large PDP-11s are 22 bits. And yet, they also have a virtual memory system. Moreover, even though the hardware of a PDP-11 allows you to design a demand paging system, noone ever did (as far as I know). However, swapping was done. This might be a good time to point of swapping. Swapping is the process of writing out or reading back the whole process context and memory from a backing store. This is different from paging, in which individual pages are read/written, and the context of the process stays in memory. Page faults are a part of the demand paging system, and occur as a part of the execution of a process. Swapping is something that happens when the process currently is suspended (maybe just because a context switch, and maybe because it is waiting for some event to happen). A page fault can cause a process to temporarily be suspended. Swapping on the other hand is something the OS decides upon because either resource shortage needs larger amounts of resources to be freed immediately, or perhaps because it appears that the resources will not be referred to for a long period.

I'm not really a good writer, so I don't feel appropriate to actually rewrite this article, but it certainly feels like people have got the three concepts totally confused. But to summarize: virtual memory - make it appear as if the whole addressable memory is "yours". Demand paging - a way of having part of program memory actually be stored on secondary storage, without the program being aware of it (unless you count timing issues). Swapping - a way of freeing up resources.

Demand paging can partly solve the resource issues as well, but can also cause thrashing and resource shortage. Demand paging is also the way of making it look like you have more memory than physically exists in the computer. Virtual memory is fundamental mechanism that is required for demand paging to work, but virtual memory do not mean that you got to have demand paging, as have been demonstrated by a number of machines.

I'll be happy to reply to any questions you might have. / -- (talk) 17:33, 30 September 2008 (UTC)

An interesting set of comments. If you can provide reliable sources for any of these points, the article should incorporate them. However I don't think your definition of "virtual memory" = "to fool a program that it is alone in memory space" is any superior to "fooling the application that it has a single block of contiguous memory" - in fact I think your definition is narrower, and therefore more easily falsified bvy a counter-example. The artcile may have to face the possibility of multiple definitions of "virtual memory", as different companies took different approaches based in the early work in the field, and then used "virtual memory" as a marketing term for their specific approaches. --Philcha (talk) 10:54, 19 November 2008 (UTC)
What would be considered reliable sources? Processor handbooks describing the virtual memory system of any of the machines I mention? One "fact" that stands out in a computer using a virtual memory system is that you can have several programs running at the same time, referring to the same virtual address, but none of those programs are in fact referring to the same location as any of the other programs running. Virtual memory is a way of abstracting away a lot of details involving the operating system and multitasking. The running program don't have to be aware of that kind of detail nor have to take it into consideration when doing something. Also, if a program runs amok and trashes memory, it is only it's own memory space that gets trashed, no other process is affected by this. That is a very important aspect of virtual memory. It's just your own memory, and noone else have anything to do with it, nor is affected by anything happening to it. The fact that it might, or might not be contiguous is pretty irrelevant, and might or might not be true for any instance. As pointed out, the virtual memory can be implemented in a paged system where each page can be anywhere in physical memory. And yet, the page table can contain invalid pages in between valid pages. So, there is no base for the assumption that memory is contiguous either physically or virtually. But then again, there is really nothing that forbids it from being so. So, saying "fooling a program that it has a single block of contiguous memory" sets an arbitrary limit on what virtual memory is for which there is absolutely no factual base. My definition might not be perfect, but I believe it is far more correct than the current article, which basically just talks about a specific way of implementing virtual memory as if that was the definition of virtual memory. I wonder if you can find a single definition of virtual memory which would allow all processes private memory to be visible in all other processes running, as well as making the OS memory available. It would be a very interesting virtual memory to learn about. But I'm all ears. Oh, and I can't imagine how a system where all processes memory were visible to everyone else would work. Address space would cause limitations on how much could be in memory at the same time, two different processes running the same image would have that same image running at different addresses, or else the view of the memory would be presented differently for each program running (and how would that be done?). Also, what about dynamic memory allocation in the face of all this? I just can't see how you could get that to work. Virtual memory is really the only way to get past that hurdle. And it's all about presenting a private memory space as if noone else was around, no matter what else is happening in the system. / -- (talk) 01:02, 9 January 2009 (UTC)
Yes, the current definition, is historically inaccurate. The term "virtual memory" on many (if not most) of the early machines was used to describe a method to increase the total working set, not to provide some kind of C/Unix/flat memory model abstraction. That is why you see machines with flat address spaces (generally via segmentation) not being labeled as having virtual memory, and machines which didn't even have MMU's (early Mac OS) being described as having virtual memory. You have to remember the mindset was that physical memory was severely limited, and a machine which allowed you to simulate more of a scare resource was truly useful. Abstractions to make writing programs easier, weren't as much of a concern when you weren't even sure if it was possible to solve the problem. The B5000 widely credited as the first commercial machine with virtual memory did _NOT_ have a flat address spaces. The "processes" were accumulated disjoint sections of memory tied to individual data structures the application needed. What it did have, was the ability to transparently swap those regions to a secondary storage mechanism without application knowledge. —Preceding unsigned comment added by (talk) 17:18, 5 December 2008 (UTC)
Since Unix is such a popular reference, I think it's rather appropriate that the PDP-11 is my source for objections most of the time. The PDP-11 is a 16-bit machine, meaning all addresses are 16 bits wide, and so on. However, the physical address space is 22 bits. Note how physical memory is much larger than virtual in a flat memory space. In addition, the PDP-11 do not have segment registers, or similar things. It have a MMU, a page table, and do page relocation. The 16-bit virtual address space is split into eight pages. Each page can be located anywhere in the 22-bit physical address space. So, for each process, the address space is a flat, virtual 16-bit address space. The MMU can set pages to not be accessible, and each page can also be a fraction of the full 8 KB. It don't need to map the whole 13 bits of address space. That's the basic concepts. With this, it would in theory be possible to write something with demand paging, or other page based virtual memory system on the PDP-11 (the MMU traps illegal memory references, and instructions can be restarted). But with only 8 pages, and loads of more physical memory than virtual, there isn't really much reason to make the effort. So, for all Unixes on PDP-11s, you do have virtual memory. And yes, it is there to present you with a flat virtual address space of 16 bits (so it was/is definitely for writing programs easier). But no, it is not page based, page driven, neccesarily contigous (either physically or virtually), or in any sense of the world a way to express that you have more virtual memory than physical memory on the machine. In the case you start having so many processes that physical memory still don't suffice, then swapping is used, to move whole jobs in and out of the swap area. So either a job is runnable, and then all memory referenced are in memory, or the job is swapped out, in which case parts might be in memory, and parts in the swap area. Anything describing virtual memory, which defines the Unixes (and other OSes on PDP-11s) as not having virtual memory just means they define virtual memory in a too restrictive way, or even plain wrong. / (talk) 15:05, 26 March 2010 (UTC)
Many virtual memory implimentations support shared memory, e.g., MULTICS, z/OS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:28, 15 June 2010 (UTC)
And some virtual memory implementations provide a single address space, possibly larger than the physical address space of the machine, in which all processes/tasks run, e.g. OS/VS1, OS/VS2 SVS, and the System/38 and AS/400 operating system. Guy Harris (talk) 09:31, 16 August 2011 (UTC)
Sigh, I see that the page have degenerated again, and once more claims that virtual memory is the same thing as paged memory. Do people really want Wikipedia to be this inaccurate? There are plenty of historical documents (such as PDP-11 processor handbooks to name one) which describes virtual memory, and which totally disagrees with what this page now talks about. Virtual memory is *not* the same thing as paged memory. Either can exist without the other. And I'm very curious to hear what the vm=paged-memory proponents would call the virtual memory of a PDP-11? / (talk) 14:48, 25 December 2012 (UTC)
FWIW, the Burroughs B5000, B5500 and B5700 had virtual memory but did not have paging. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:33, 27 December 2012 (UTC)
Virtual memory is also not about "to fool a program that it is alone in memory space, and that the whole memory space is exclusively for use by that program. Memory space starts at address 0 (well, it can be elsewhere as well, if it makes more sense), continues with or without holes in it, but the memory is not shared with other uses/users." As I noted, some systems run all processes in the same virtual address space - and this is not just some old technique superseded by giving every process its own address space; see some of the OSes listed in single address space operating system, such as IBM i and Singularity. Guy Harris (talk) 21:50, 25 December 2012 (UTC)

Removal of first part[edit]

I removed the following part:

Where is it? and how to change it?

In Windows XP go to "My Computer" > Right click on white part then "Properties" > "Advanced" tab > in Performance Box click "Settings" > Virtual Memory box "change"

All this is stored in a File named PAGEFILE.SYS

Wikipedia is not a howto ! (and the writing style is pretty poor) --G.ardaud (talk) 08:15, 19 November 2008 (UTC)

"Developed for multitasking kernels" not right?[edit]

Apologies if I've reverted prematurely. I was very much under the impression that is exactly what virtual memory and paging functions were about. And throw memory protection in there too.

Having now read more about the early mainframes and research computers I am now getting the impression that the executable was often streamed through RAM like the RAM was a cache. Is caching a good analogy?

If so, then I can see why the paging idea was an important step independent of multitasking. That said, I suspect such functionality can be achieved with just software when not multitasking.

Evanh (talk) 12:09, 21 November 2009 (UTC) Edited for clarity Evanh (talk) 14:10, 21 November 2009 (UTC)

The claim is not exactly wrong, but it at least overstates the relationship between VM and multitasking OS.
To put it as generally as possible: VM was developed to allow a workload to proceed as if all of the address space it had defined was present in the memory directly addressable by the instruction set, even though the actual RAM available to that workload was smaller than "all of the address space it had defined," and without the workload having to manage the memory by itself.
It doesn't really matter if the workload involves multitasking or not.
Consider VM as an alternative to the old scheme of code overlays, where the workload is responsible for calling the overlay functions to bring in various blocks of code. VM has the same effect, except that it works at a much finer granularity, and it works automatically, and of course it works for data regions too.
Now it is certainly the case that much of what we regard as the foundations of actual, realized, modern implementations of VM were developed as part of multitasking kernels. This may or may not be an accident of timing: there have been darned few significant, truly single-tasking kernels in the past few decades. And VM and multitasking do work very nicely together, as VM allows the kernel to effectively share the common memory resource across all of the tasks.
But as the article stands now, I think it's overstating the relationship between the two.
Re "cache", that IS a good analogy. The RAM is a cache for the most interesting things that are on the disk - automatically managed by the VMM. The CPU's internal cache is a cache for the most interesting things in RAM, the CPU's registers (the ones accessible to the instruction set) are a cache for the most interesting things from the internal cache, and the register file (seen only by the microcode) acts as a cache for those... Jeh (talk) 23:06, 26 June 2010 (UTC)

Burroughs large systems did have paging[edit]

While the B5000, B5500 and B5700 only had segmentation, the large B6500 series had a completely different architecture, which included both paging and segmentation.

FWIW the Unisys line includes only the B6500 architecture, not the B5000 architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:34, 15 June 2010 (UTC)

Virtual=real has major errors[edit]

In IBM's OS/VS1, OS/VS2 (SVS) and MVS, V=R played a very limited role. The system had provision for temporarily page fixing storage, including I/O buffers; that was not something added in later releases. Programs using Execute Channel Program (EXCP) and building their own channel programs did not have to run V=R; the I/O Supervisor did the necessary page fixing and CCW translation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:54, 27 June 2010 (UTC)

Base and bound is not segmentation[edit]

A recent edit refered to segmentation as synonymous to segmentation; that is incorrect. With base and bound a program has access only to a single contiguous instruction area and to a single contiguous data area. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:47, 5 July 2010 (UTC)

I guess you meant "A recent edit refered to base and bound as synonymous to segmentation"? Jeh (talk) 01:54, 14 July 2010 (UTC)
Yes; thanks.
One minor correction is that some systems had separate storage areas for instructions and data. I'm not sure whether mention of that would be TMI in the article.Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:42, 15 July 2010 (UTC)

Level of detail for edge cases and nonstandard nomenclature[edit]

I have some policy questions inspired by the Burroughs B5000 and B6500 product line, but which probably apply to other architectures as well.

  • Is it appropriate to mention occasional nonstandard nomenclature, e.g., the use by Burroughs of the term segmented to refer to the splitting of a large segment into independently mapped 256 word pages?
  • Is it appropriate to mention techniques such as nested segments, or is that TMI.

Virtual memory traits[edit]

Two features of some virtual memory systems that it might be appropriate to discuss in the introduction are that it is common to have provision for shared virtual memory and that some virtual memory systems have more flexible access controls than is feasible without address translation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:12, 22 July 2010 (UTC)

Hardware support for emulators and virtual machines[edit]

It is certainly common to write simulators without hardware support, but I am not aware of any emulator for a system with virtual memory that does not have hardware memory mapping for the emulated system, and I am not aware of any virtual machine facility that does not use hardware memory mapping for the virtual machine.

Note that emulation was defined as a combination of host software, microcode and hardware, not as simulation using only the standard host instruction set. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:19, 22 July 2010 (UTC)

An emulator produces the same results as the original equipment had achieved. A simulator fools the application into thinking the same results have been achieved without actually doing anything. Evanh (talk) 00:43, 1 September 2010 (UTC)
I have to agree with Chatul here. Virtual machines especially rely on heavily MMUs if they are any good. (i.e. they try their best to run the code natively, and react to hardware faults.) I would expect any emulator that needs to support an MMU would do the same, unless they wanted to be really slow, i.e. run tons of extra code at every memory access. (talk) 22:36, 10 September 2011 (UTC)

Where to discuss channel program translation[edit]

{{Helpme}} In several lines of IBM mainframes, e.g., z/OS, an unprivileged application can prepare its own channel program and request its performance with the EXCP (Execute Channel Program). EXCP performs functions such as page fixing, address mapping and channel program translation. As the article is currently structured I don't see a good place to describe EXCP or similar facilities in other systems. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:01, 22 July 2010 (UTC)

We already seem to have an article at Unit Control Block. You could try including it in the "history" section if it's a function which arose with a particular system. Ironholds (talk) 14:37, 22 July 2010 (UTC)
I have only vague notions of IBM's channels and channel control programs. But I believe this function is in what is commonly referred to these days as an I/O MMU (I/O Memory Management Unit). Jeh (talk) 19:53, 22 July 2010 (UTC)
Hmn. I'd suggest asking at Wikipedia talk:WikiProject Computing; it's rather a specialist question. Ironholds (talk) 00:17, 23 July 2010 (UTC)
The material that I want to add is software, not hardware. There is no I/O MMU on IBM's flagship mainframe line, althugh there once was a facility called ECPS:VSE that provided the functionality in microcode. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 25 July 2010 (UTC)
There's already material in the UCB article that I've suggested removing. CCW translation doesn't belong there either. I'll take Ironholds's suggestion and ask in Wikipedia talk:WikiProject Computing. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 25 July 2010 (UTC)
Seems good. fetch·comms 01:55, 26 July 2010 (UTC)
I got around to reading this section only after I changed the article Channel_I/O to include a section on CCW translation, but that still seems the appropriate place for it to me. Peter Flass (talk) 19:33, 6 March 2012 (UTC)

Paging page tables[edit]

I've just tagged as dubious an assertion that page tables are not usually paged. There is no source for that assertion and certainly pages tables may be paged. I can't cite any particular systems off the top of my head but I remember covering this distinctly at Uni over ten years ago. Although it does complicate memory management it is not insurmountable and I was under the impression that is was common practice for a full-featured implementation. I'll start up up some particular systems but the "usually" element is always going to be problematic. Does anyone have any sources for that assertion? Crispmuncher (talk) 14:16, 22 July 2010 (UTC)

On Windows x86/x64, all but the top-level table (PD without PAE, PDPT with PAE, PML4 on x64) can be paged. VAX did not use multilevel PTs but the P0 and P1 page tables can be paged, while the system PT cannot be. So, yes, at least some page tables can certainly be paged, and indeed this is done in the most widely used OS in the world. Jeh (talk) 19:51, 22 July 2010 (UTC)
Windows is not even close to the most widely used OS in the world. It is merely the most widely used DESKTOP OS in the world. More over, that doesn't invalidate the point; many page tables STILL cannot be paged. The fact SOME can doesn't mean anything to the statement made. —Preceding unsigned comment added by (talk) 23:26, 9 November 2010 (UTC)
Regardless of what the most widely used OS is (a point that as far as I can tell was never raised and was never in contention), the claim vastly overstated the case. Corrected. Jeh (talk) 19:03, 17 November 2010 (UTC)
"Page tables are usually so large that they are stored in main memory and are sometimes paged themselves" From "Computer Architecture: A Quantitative Approach 4th Ed" by John L. Hennessy and David A. Patterson, Appendix C p. C-44.

Prevalence of virtual memory operating systems in the 1960′s and early 1970's[edit]

The claim Consequently, older operating systems (such as DOS[1] of the 1980s or those for the mainframes of the 1960s) generally have no virtual memory functionality is questionable. Even if you exclude block relocation as not being virtual memory, at least the following vendors shipped commercial paging computers in the 1960's:

  • CDC
  • DEC
  • GE/Honeywell
  • RCA
  • SDS
  1. ^ "Windows Version History". Microsoft. Last Review: July 19, 2005. Retrieved 2008-12-03.  Check date values in: |date= (help)

Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:53, 17 November 2010 (UTC)

"Generally" is probably true. The only DEC boxes with paging in the 1960's were the ones with the add-on BBN pager, and the IBM System/360 Model 67, GE 645, SDS 940, and RCA Spectra 70/46 were all special variants of the S/360, GE 600, SDS 900, and Spectra 70 lines. What was the paging CDC machine of the 1960's?
Paging definitely was mainstream by the early '70's, however, given S/370 and {DOS,OS}/VS. Guy Harris (talk) 23:21, 5 July 2011 (UTC)
Even if you ignore paging models of otherwise non-paging product lines, you have
  • CDC STAR-100
  • Ferranti Atlas and Titan
  • SDS Sigma-7
Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:10, 15 August 2011 (UTC)
The CDC STAR-100 was, at least according to the Wikipedia article for it, "announced very early during the 1970s" and "first used commercially in 1974", so it doesn't sound like a paging computer of the '60's. According to the page for the Ferranti Titan, it "had a real, but cached, main memory, rather than the paged (or virtual) memory used in the Manchester [Atlas] machine". So, for the '60's, we have:
  • Atlas (about which I already knew, and of which only 3 were built, according to the Wikipedia article)
  • PDP-10 with the BBN pager added (which I mentioned above)
  • GE 645 (which I mentioned above)
  • IBM System/360 Model 67 (which I mentioned above)
  • RCA Spectra 70/46 (which I mentioned above)
  • SDS 940 (which I mentioned above)
  • SDS Sigma 7
most of which were, as I stated above, special variants of a general line of computers of which most shipped, as far as I know, without virtual memory - the only exceptions were the low-volume Atlas and the Sigma 7. So I've not seen anything to indicate that one should not state that "older operating systems (such as ... those for the mainframes of the 1960s) generally have no virtual memory functionality"; nobody's given any statistics showing that, of the systems shipped in the 1960's, either a majority or significant minority had VM hardware and software. The 1970's were, as I indicated above, different - but the page doesn't say "of the 1960s and early 1970s, it just says "of the 1960s". Guy Harris (talk) 23:08, 15 August 2011 (UTC)

The SDS 940 and Sigma systems in the 60s had virtual memory. If you want to count boxes, IBM outweighs everyone else, but if you want to count systems or families, I'd say maybe many older operating systems..." Peter Flass (talk) 00:31, 27 October 2011 (UTC)

At this point, if you include non-vendor OSes, the '60's-vintage OSes I know of that supported VM are:
(any similarity between that list and the above list of machines supporting VM is not coincidental :-)). In terms of a raw count of OSes, regardless of how many instances were shipped, is that enough to rule out "generally"? (If you count systems shipped, I suspect you can't rule out "generally".) Guy Harris (talk) 07:07, 27 October 2011 (UTC)

Meta: {{Page needed}}[edit]

The is a reference for Virtual=Fixed (V=F) that is tagged with {{Page needed}}; however, that template is inappropriate because the reference does not have page numbers. I wanted to replace the {{Page needed}} template with a more appropriate one, but I couldn't find a template for subsection URL needed. There are other references for V=F. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:53, 17 November 2010 (UTC)

On suitable reference is "Central Storage Considerations for User Programs". z/OS V1R11.0 MVS Programming Assembler Services Guide z/OS V1R10.0-V1R11.0. SA22-7605-11.  Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:45, 9 February 2011 (UTC)

PDP-10 and Virtual Memory[edit]

"To allow for multiprogramming and multitasking, many early systems already had the ability to divide the memory between multiple programs even without providing virtual memory; for instance, early models of the PDP-10 provided memory access through what are called base and bounds registers."

The "early models" of PDP-10 you are talking about are the KA10 processor and its predocessor the model 166 processor of the PDP-6 computer. The later models (KI10, KL10, KS10) all had demand paging virtual memory management. However, the idea that the KA10 didn't provide virtual memory is wrong. It provided a two segment memory model (shared and private) via two sets of base, protection, and length registers. Every user memory address was automatically translated as part of access and every process (job in tops-10) had its own image of memory. This is virtual memory.

what is virtual memory pracically? —Preceding unsigned comment added by (talk) 16:56, 23 February 2011 (UTC)

I'd say a key characteristic of virtual memory is that, on a system with virtual memory, a single process (or equivalent) can run in an address space larger than the machine's physical memory. If all the pages/segments of a process (job, task, whatever) must be in memory in order for the process to be runnable, I wouldn't call that virtual memory, even if the OS swaps jobs in and out of memory, so that the sum of the sizes of all the processes on the system is greater than the machine's physical memory. This wouldn't include the KA10 and the TOPS-10's that ran on them, but it would include paging systems as well as segmenting systems that don't require all of a process's segments to be in main memory and that can dynamically fault segments into memory and move them out of memory. Guy Harris (talk) 23:34, 5 July 2011 (UTC)
Note that, given, for example, OS/VS1 and OS/VS2 SVS, this could be done without giving each process its own virtual address space; they packed multiple processes into a single virtual address space, in the same way their predecessors packed them into the physical address space. The virtual address space could presumably be bigger than the machine's physical address space, so you could still have a process (job) run that wouldn't fit in physical memory. Guy Harris (talk) 23:43, 5 July 2011 (UTC)

Base and bound is virtual memory.[edit]

If the system has base/bound registers, for example the early ICT 1900 series then user programs do not manipulate physical addresses they manipulate virtual addresses.

Or, to look at it another way base/bound is a degenerate case of segmentation -- the process only has one segment. (Or two on PDP 10). HughesJohn (talk) 11:05, 23 March 2011 (UTC)

See my comment in the PDP-10 section above; I'd say virtual memory needs more than relocation and protection, it needs to let a process run even if all of its address space isn't in main memory, with pages/segments/whatever dynamically pulled into memory as the result of a "not present" fault and other pages/segments/whatever evicted, if necessary, to make room for them. Perhaps there needs to be a term for relocation+protection, but if that term is "virtual memory", another term is needed for relocation+protection+not all the address space needs to be in main memory (and "paged virtual memory" isn't it, as that doesn't include segment swapping). Guy Harris (talk) 23:38, 5 July 2011 (UTC)
"I'd say virtual memory needs more than relocation and protection, it needs to let a process run even if all of its address space isn't in main memory,"
I'd say that a virtual memory means virtual addresses. In a virtual memory system programs don't manipulate real addresses, there is some translation from virtual addresses to real addresses. To me base and bound is a degenerate version of segmentation - base/bound system only allows one segment per program. HughesJohn (talk) 16:31, 28 October 2011 (UTC)
There needs to be a distinction between "instruction and data addresses are not physical addresses in main memory, but all of the addresses in the address space need to have a physical address in main memory to which they correspond" and "instruction and data addresses are not physical addresses in main memory, and not all of the addresses in the address space have to have a physical address in main memory to which they correspond - a reference to a location that doesn't have such a physical address will cause a physical address to be assigned to that location (and presumably some part of the address space near that location) and the appropriate bits put there". If there's a consensus that "virtual memory" should refer to the former (and that consensus is supported by the way the term "virtual memory" is actually used in computer engineering!), then this page needs a lot of reorganization, possibly including creating a page for the latter. (A distinction might also be desired between "swapping" in the sense of a system where a process/application/whatever needs to have all its address space in main memory when it's running, but a process that's not running could have some or all of its core and data in secondary storage, with that code and data moved into main memory when the process is scheduled to run.)
I.e., there's "virtual" as in "not equal to physical" and "virtual" as in "not necessarily in physical memory"; the latter implies the former (although I suppose I might be missing a system where, for example, demand paging makes sense when a given non-resident page always gets paged into the same physical page, and that page is unusable except by that particular page), but involves a lot more than just the former. Guy Harris (talk) 17:50, 28 October 2011 (UTC)
"If there's a consensus that "virtual memory" should refer to the former (and that consensus is supported by the way the term "virtual memory" is actually used in computer engineering!), then this page needs a lot of reorganization."
It's pretty clear to me that this page needs rewriting. I mean, look how it starts "In computing, virtual memory is a memory management technique developed for multitasking kernels.". Bleaurgh, a-historical nonsense. I'm looking for good references. HughesJohn (talk) 14:26, 29 October 2011 (UTC)
No, "instruction and data addresses are not physical addresses in main memory, but all of the addresses in the address space need to have a physical address in main memory to which they correspond" is 'not the way the term "virtual memory" is actually used in computer engineering!); the way that it is actually used is that pages in the auxilliary (paging) files do not have corresponding real storage addresses.
BTW, I am aware of one case where pages are remapped without any involvement with the normal paging mechanism; it's called prefixing[NB 1] and causes translation of real address 0[NB 2] to an absolute address associated with the processor. I don't consider prefing to be virtual storage, but others may disagree.
  1. ^ Originaly implimented on the 360/65 MP, but the details changed on the S/370 multiprocessors.
  2. ^ On the S/370, the term real address refers to addresses after page translation but before prefing; the term absolute address corresponds to the actual physical address.
Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:40, 1 November 2011 (UTC)

Systems using memory map registers[edit]

This discussion doesn't cover systems that implement virtual memory via memory map registers rather than page tables. I'm thinking of the SDS 940 and Sigma systems, but I imagine there are others.Peter Flass (talk) 00:26, 27 October 2011 (UTC)

Sun-1, Sun-2, Sun-3 (except for Sun-3x), Sun-4 (prior to the Sun-4d and Sun-4m). Guy Harris (talk) 04:29, 27 October 2011 (UTC)
I believe that the CDC 3800 used memory map registers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:42, 1 November 2011 (UTC)
Was it the SDS 940 that did paging? My recollection is SDS 945. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:06, 12 December 2011 (UTC)
According to this section of a Web article:
By February 1966, SDS announced the SDS 940, a time-sharing system which was backward compatible with the previous systems (except the SDS 92 which was a 12 bit computer). It had monitor and user modes, dynamic program relocation, automatic memory fragmentation, and system protection. "You'll still be contented using your 940 system five years from now" - was advertised in 1966. Today (1984) SDS 940s still run Tymshare's Tymnet and Comshare uses at least two. The University of California at Berkeley worked with Tymshare and SDS on this early time-sharing system.
In 1968 the SDS 945 was advertised as an SDS 940 with less expandibility but just as much compute power. The design of the SDS 940 is very complex because of the backward compatibility with the 930 etc. and the needed changes to support time-sharing. The design of the Sigma 7 can readily be seen as a simplification and extension.
so it sounds as if they both did paging. Guy Harris (talk) 20:21, 12 December 2011 (UTC)


Segmented virtual memory: "systems with this memory structure, such as Multics and IBM System/38, are usually paging-predominant." 1) What exactly does this mean? 2) What is/are other alternatives and who uses them? This sounds like an interesting concept that is dropped in here with no amplification.Peter Flass (talk) 13:54, 10 November 2011 (UTC)

Embedded situations[edit]

The part about embedded systems doesn't really make sense, especially the part about bit-banging. (If you have a real-time system and use a system where a page fault could trigger I/O (e.g. you are using a demand paging system), you have a significantly bigger problem than merely the fact that you are using bit-banging for I/O accesses. (Wikipedia newbie, non-registered user) — Preceding unsigned comment added by (talk) 19:51, 28 December 2011 (UTC)


On 15 February 2012 Daniel Santos said "(Removing old unsourced claim. I do not believe it's true, but if somebody wants to get a good source on it, then they can re-add it. Efficiency gains from reduced fragmentation can be offset by the overhead of memory mappings and context switching.)"

I think the claim was the VM systems use "hardware memory" more efficiently, not necessarily the whole system. I don't have a source handy, but consider a system like MVT that needed contiguous physical memory equal to "region size" before starting a job. Large chunks of memory might have to sit unused waiting for something to end to free enough contiguous storage. A system like MVS would be able to start the job immediately and fill up physical memory with the working sets of all active jobs.

Of course this caused other problems, but memory sure could be fully used. Peter Flass (talk) 13:22, 15 February 2012 (UTC)

The validity of the claim is not limited to VM; in fact, you mention MVS, which is an example of a system using hardware memory more efficiently than its real predecessor, OS/360. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:02, 1 March 2012 (UTC)
(By "The validity of the claim is not limited to VM" do you mean "VM" as in "virtual memory" or as in "virtual machine"?) Guy Harris (talk) 00:37, 2 March 2012 (UTC)
I was talking about virtual memory, I thought that was what the original claim was about... Peter Flass (talk) 13:04, 2 March 2012 (UTC)
My question was asking what User:Chatul meant by "VM" in "The validity of the claim is not limited to VM"; if he meant "virtual memory", that statement makes no sense to me, given that MVS supported demand-paged virtual memory, so MVS had "VM" in that sense, so I was wondering if he thought "VM systems" meant "systems running VM" rather than "systems with virtual memory". Guy Harris (talk) 17:48, 2 March 2012 (UTC)
I took VM to be a reference to VM (operating system) rather than to Virtual machine or Virtual memory . Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:57, 2 March 2012 (UTC)

Embedded Systems Complex Memory Hierarchy Reference[edit]

Removed an uncited sentence asserting that embedded systems don't need a complex memory hierarchy as per WP:FORUM Random2001 (talk) 21:13, 7 March 2012 (UTC)

Terminology for pages locked into physical memory[edit]

Just for fun, I took at look at the mlock() man page in OS X, and it mainly uses "locked (into memory)". The HISTORY section of the man page says "The mlock() and munlock() functions first appeared in 4.4BSD.", so the *BSD man pages probably are the same or very similar. The Solaris and HP-UX pages also speak of locking pages in memory. The Linux mlock() page speaks of "disabling paging", and the AIX page speaks of "[causing] those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes to be memory-resident until unlocked...".

So I'm not sure for which operating systems the term is "pinned". This question speaks of "pinned pages" on AIX; I'm not sure the output with "pinned" in it is from an AIX command or not. OS X's Activity Monitor uses "wired", but I don't know offhand whether those pages are only pages "wired" by virtue of being, for example, kernel code or data pages, or whether it includes pages locked into memory because I/O is being done to or from them or if they've been mlock()ed. This knowledgebase entry for VMware speaks of "pinned pages (sometimes called locked pages)". Guy Harris (talk) 21:58, 26 May 2012 (UTC)

A reference for the term page fix in z/OS and earlier systems is z/OS V1R12.0 MVS Programming Authorized Assembler Services Guide, SA22-7608-15 Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:01, 1 June 2012 (UTC)

Question on Referencing My Own Book[edit]

I recently published a book on the internals of the virtual memory manager of Windows and I would like to know if I am allowed to add a bibliographic reference to it on this page.

I have a personal interest a stake, because I would like as many people as possible to know that my book exists. At the same time, I think readers of this article would benefit from this information, since the book is relevant to the subject at hand.

In the event that I am allowed to add such a reference, would it be correct to place it in the Further Reading section?

Below are the book reference data, thanks.

Title: What Makes It Page? Author: Enrico Martignetti Publisher: CreateSpace Independent Publishing Platform Publicaton date: August 21, 2012 ISBN-10: 1479114294 ISBN-13: 978-1479114290 EnricoMartignetti (talk) 15:46, 19 February 2013 (UTC)

It is allowed, but please follow these guidelines: Ehamberg (talk) 21:22, 19 February 2013 (UTC)
Thank you, I have read the guidelines and I have a further question: my book is self-published and it's my only publication, so I cannot claim to be a recognized expert in this field. However, the book is receiving positive evaluations, including two customer reviews on Amazon, ranking it at 5 out of 5 stars. Given all this, can I still add it to the Further Reading section? I am convinced that the book content is relevant, so my misgivings are only about it being self-published. Thanks again. EnricoMartignetti (talk) 13:51, 20 February 2013 (UTC)
I am about to add my book to the Further Reading section. I believe this is a useful piece of information for readers interested in this subject.EnricoMartignetti (talk) 11:05, 4 March 2013 (UTC)
Sorry your book listing looks like self-promotion to me. I think it would be more likely to be acceptable if you had referenced your book in some part of the article itself. But simply listing it as further reading seems like advertising, and as the author you should probably not be the one doing that. — Preceding unsigned comment added by Gabriel.Southern (talkcontribs) 23:40, 22 May 2013 (UTC)

Virtual memory does not imply paging[edit]

While it is true that the first computer with a virtual memory, the Ferranti Atlas, used paging, it was quickly followed by the Burroughs B5000, which used segmentation but not paging. The recent revision to the introduction of Virtual memory defines virtual memory strictly in terms of paging. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:37, 6 August 2013 (UTC)

Agreed. Reverted. Jeh (talk) 18:14, 6 August 2013 (UTC)
OTOH I don't really like the current text either - I think it's long-winded. Peter Flass (talk) 18:41, 6 August 2013 (UTC)
The intent of my change was to describe virtual memory in terms of address translation in hardware coupled with software that can extend the capabilities of the hardware, something the current text fails to do. While there have been various hardware implementations that do not use pages, most do, since that methodology easily extends the capability to demand paging. IBM's first machines with VM used segmentation tables and page tables, but so what? Most people reading the article will be totally confused by the complex address translation. The main intent of my article was to stress that memory withing the hardware can be addressed in two ways: real and virtual. If you all feel that selecting page tables as an example of how to to do that was inappropriate, then why not follow the idea of trying to write a coherent explanation and modify what I said.
I would be hard pressed to decide what are the greatest benefits provided by VM. Certainly demand paging would appear as the most useful in single user systems and the combination of discreet address space and demand paging in multi user systems. Discreet memory today would probably be useful without demand paging, since we have 64 bit memory addresses and cheap memory. In the days when VM was designed, 64K cost millions of dollars, so the ability to use that memory more efficiently was far more important than discreet addressing. The early 360 models were multi user, but did not have virtual memory. Those systems used memory protection with a protection key assigned to each task. The model 67 used virtual memory, but did not come into being until later in the life of the 360, the computer that dominated the entire world. IBM needed a way to provide more memory without driving the cost to prohibitive levels. VM provided the methodology to accomplish that and allowed IBM to sell many more computers. The impact of this significantly enlarged IBMs market and changed the way corporations handled large amounts of data. The ability to provide more memory at no additional cost had much greater historical impact on the computer industry than discreet address spaces. Andiamo1 (talk) 09:53, 10 August 2013 (UTC)
Giving paging as an example of VM is OK. Saying
It allows memory to be addressed using a set of hardware tables that provide a view of memory that is contiguous even though the pages that make up real memory are discontiguous . In other words, the memory appears to be in a set of pages that are addressed using an address counter that is incremented sequentially from the lowest to the highest memory address.
doesn't give it as an example, it gives it as an required aspect; in systems with segmented and unpaged virtual memory, real memory isn't made up of pages, and the memory doesn't appear to be in a set of pages, but the system nevertheless has virtual memory. Guy Harris (talk) 19:29, 10 August 2013 (UTC)
How about this?

"In computing, virtual memory is a memory management technique that is implemented using both hardware and software. It maps memory addresses used by a program, called virtual addresses, into physical addresses in computer memory. Main storage as seen by a process or task appears as a contiguous address space or collection of contiguous segments.

The operating system manages virtual address spaces and the assignment of real memory to virtual memory. Address translation hardware in the CPU, often referred to as a memory management unit, automatically translates virtual addresses to physical addresses. Software within the operating system may extend these capabilities to provide a virtual address space that can exceed the capacity of real memory and thus reference more memory than is physically present in the computer."

Peter Flass (talk) 13:30, 10 August 2013 (UTC)

I think it's good. In any case, it's a substantial improvement over what is on the public page. I also think it's important to provide some history and emphasize that VM's ability to extend real memory had much more of an impact on computing than just a virtual address space. Andiamo1 (talk) 19:36, 10 August 2013 (UTC)


As far as I know, thrashing requires neither paging nor page stealing in the form in which it's described in the paging article. It just requires that some form of demand loading be done (so that the entire address space of a process need not reside in main memory, with stuff loaded when it's referred to) and that not enough physical memory be available for the working sets of all processes considered "runnable" (so that trying to run process A could require that pages or segments from runnable process B be removed from memory, in order to load pages or segments from process A); that could presumably happen with segmentation if you demand-load segments. Guy Harris (talk) 19:55, 25 November 2013 (UTC)

Pageable versus swappable[edit]

A note on the last update to Virtual memory#Pinned pages: In IBM mainframe operating systems, e.g., z/OS, page fixing applies to individual pages and swapping refers to entire address spaces. A long term page fix does not render an address space unswappable, nor does making an address space un swappable cause page fixing. Thus an application can never be fixed, only unswappable.

Of course, a V=R application is both unswappable and pinned, but it is a rare special case; I'm not even sure whether it it is still supported. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:13, 29 May 2014 (UTC)

" page fixing applies to individual pages and swapping refers to entire address spaces. " This is the terminology used in VMS and Windows 8 as well, although some of the nuances are different. Also, (m) fixed spelling and formmating in previous Jeh (talk) 18:10, 29 May 2014 (UTC)

Paging vs RAM drive (See also)[edit]

  • Paging: scheme by which a computer can store and retrieve data from secondary storage for use in primary storage
  • RAM drive: block of primary storage that a computer's software uses as secondary storage

I think that, at least conceptually, paging is the opposite of RAM drive. So RAM drive should appear at least in "See also". --Edupedro (talk) 08:10, 21 July 2014 (UTC)

Let's have this discussion in one place. I have already answered at the RAM drive talk page. Thanks. Jeh (talk) 08:38, 21 July 2014 (UTC)