[go: up one dir, main page]

Virtual memory: Difference between revisions

Content deleted Content added
No edit summary
Tag: Reverted
Citation bot (talk | contribs)
Altered title. Add: chapter-url, chapter. Removed or converted URL. | Use this bot. Report bugs. | Suggested by Headbomb | #UCB_toolbar
 
(5 intermediate revisions by 3 users not shown)
Line 1:
{{Short description|Computer memory management technique}} BIGGIE ON A CIGGIE
 
{{About|the computer memory management technique|
the technique of pooling multiple storage devices|Storage virtualization|
Line 13 ⟶ 12:
| section = SYSTEM COMPONENTS: Dynamic Relocation
| page = 21
| year = 1966
| url = http://bitsavers.org/pdf/ibm/360/tss/C20-1647-0_360-67_TSS_Tech.pdf
| section-url = http://bitsavers.org/pdf/ibm/360/tss/C20-1647-0_360-67_TSS_Tech.pdf#page=21
Line 74 ⟶ 73:
The first true virtual memory system was that implemented at the [[University of Manchester]] to create a one-level storage system<ref>{{citation | last1=Kilburn | first1=T. | last2=Edwards | first2=D.B.G. | last3=Lanigan | first3=M.J. | last4=Sumner | first4=F.H. | title=One-level Storage System | journal=IRE Trans EC-11 | pages=223–235 | year=1962| issue=2 | doi=10.1109/TEC.1962.5219356 }}</ref> as part of the [[Atlas Computer]]. It used a [[paging]] mechanism to map the virtual addresses available to the programmer onto the real memory that consisted of 16,384 words of primary [[magnetic-core memory|core memory]] with an additional 98,304 words of secondary [[drum memory]].<ref>{{cite web|url=https://www.ourcomputerheritage.org/Maincomp/Fer/ccs-f5x2.pdf|title=Ferranti Atlas 1 & 2 – Systems Architecture|date=12 November 2009}}</ref> The addition of virtual memory into the Atlas also eliminated a looming programming problem: planning and scheduling data transfers between main and secondary memory and recompiling programs for each change of size of main memory.<ref>{{cite encyclopedia |last=Denning |first=Peter J. |entry=Virtual memory |date=1 January 2003 |entry-url=https://dl.acm.org/doi/abs/10.5555/1074100.1074903 |encyclopedia=Encyclopedia of Computer Science |pages=1832–1835 |publisher=John Wiley and Sons |isbn=978-0-470-86412-8 |access-date=10 January 2023}}</ref> The first Atlas was commissioned in 1962 but working prototypes of paging had been developed by 1959.<ref name="denning"/>{{rp|page=2}}<ref>{{cite journal |first=R. J. |last=Creasy |url=http://pages.cs.wisc.edu/~stjones/proj/vm_reading/ibmrd2505M.pdf |title=The origin of the VM/370 time-sharing system |journal=[[IBM Journal of Research & Development]] |volume=25 |issue=5 |date=September 1981 |page=486|doi=10.1147/rd.255.0483 }}</ref><ref>{{cite web|url=http://www.computer50.org/kgill/atlas/atlas.html|title=The Atlas|archive-url=https://web.archive.org/web/20141006103119/http://www.computer50.org/kgill/atlas/atlas.html|archive-date=6 October 2014|url-status=usurped}}</ref>
 
As early as 1958, [[Robert S. Barton]], working at Shell Research, suggested that main storage should be allocated automatically rather than have the programmer being concerned with overlays from secondary memory, in effect virtual memory.<ref name="Waychoff 1979">{{cite web |last1=Waychoff |first1=Richard |title=Stories About the B5000 and People Who Were There |url= https://archive.computerhistory.org/resources/access/text/2016/06/102724640-05-01-acc.pdf |website=Computer History Museum}}</ref>{{rp|49}}<ref name="IEEE-Computer-Aug-1977">{{cite web |title=IEEE Computer August 1977 David Bulman’sBulman's Letter to the Editor |url=https://www.computer.org/csdl/magazine/co/1977/08/01646583/13rRUxbCbsW
|website=IEEE}}</ref> By 1960 Barton was lead architect on the Burroughs B5000 project. From 1959 to 1961, W.R. Lonergan was manager of the Burroughs Product Planning Group which included Barton, Donald Knuth as consultant, and Paul King. In May 1960, UCLA ran a two-week seminar ‘Using and Exploiting Giant Computers’ to which Paul King and two others were sent. Stan Gill gave a presentation on virtual memory in the Atlas I computer. Paul King took the ideas back to Burroughs and it was determined that virtual memory should be designed into the core of the B5000.{{r|Waychoff 1979|p=3}}. Burroughs Corporation released the B5000 in 1964 as the first commercial computer with virtual memory.<ref>{{Cite book|first=Harvey G.|last=Cragon|title=Memory Systems and Pipelined Processors|publisher=Jones and Bartlett Publishers|page=113|year=1996|url=https://books.google.com/books?id=q2w3JSFD7l4C|isbn=978-0-86720-474-2}}</ref>
 
Line 91 ⟶ 90:
[[Page table]]s are used to translate the virtual addresses seen by the application into [[physical address]]es used by the [[Computer hardware|hardware]] to process instructions;<ref>{{cite book|last1=Sharma|first1=Dp|title=Foundation of Operating Systems|date=2009|publisher=Excel Books India|isbn=978-81-7446-626-6|page=62|url=https://books.google.com/books?id=AjWh-o7eICMC&pg=PA62|access-date=18 July 2017}}</ref> such hardware that handles this specific translation is often known as the [[memory management unit]]. Each entry in the page table holds a flag indicating whether the corresponding page is in real memory or not. If it is in real memory, the page table entry will contain the real memory address at which the page is stored. When a reference is made to a page by the hardware, if the page table entry for the page indicates that it is not currently in real memory, the hardware raises a [[page fault]] [[trap (computing)|exception]], invoking the paging supervisor component of the [[operating system]].
 
Systems can have, e.g., one page table for the whole system, sseparate BIGGIEpage tables for each address space or process, separate page tables for each segment; similarly, systems can have, e.g., no segment table, one segment table for the whole system, separate segment tables for each address space or process, separate segment tables for each ''region'' in a tree{{efn|On [[IBM Z]]<ref>{{cite book
| title = z/Architecture - Principles of Operation
| id = SA22-7832-13
Line 142 ⟶ 141:
 
==Segmented virtual memory==
Some systems, such as the [[Burroughs Corporation|Burroughs]] B5500,<ref>{{cite book|author=Burroughs|id=1021326|title=Burroughs B5500 Information Processing System Reference Manual|url=http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1021326_B5500_RefMan_May67.pdf|year=1964|publisher=[[Burroughs Corporation]]|access-date=28 November 2013}}</ref> and the current Unisys MCP systems<ref name="“MCP-VM">{{cite web |title=Unisys MCP Virtual Memory |url= https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023206.html |website=Unisys}}</ref> use segmentation instead of paging, dividing virtual address spaces into variable-length segments. Using segmentation matches the allocated memory blocks to the logical needs and requests of the programs, rather than the physical view of a computer, although pages themselves are an artificial division in memory. The designers of the B5000 would have found the artificial size of pages to be [[Procrustes|Procrustean]] in nature, a story they would later use for the exact data sizes in the [[Burroughs B1700|B1000]].<ref name="“B1000-Procrustes">{{cite webbook |titlechapter=Design of the Burroughs B1700 |chapter-url= https://dl.acm.org/doi/10.1145/1479992.1480060 |website=ACM|date= 1972 |doi= 10.1145/1479992.1480060 |last1= Wilner |first1= W. T. |title= Proceedings of the December 5-7, 1972, fall joint computer conference, Part I on - AFIPS '72 (Fall, part I) |pages= 489–497 |isbn= 978-1-4503-7912-0 }}</ref>
 
In the Burroughs and Unisys systems, each memory segment is described by a master [[Data descriptor|descriptor]] which is a single absolute descriptor which may be referenced by other relative (copy) descriptors, effecting sharing either within a process or between processes. Descriptors are central to the working of virtual memory in MCP systems. Descriptors contain not only the address of a segment, but the segment length and status in virtual memory indicated by the ‘p-bit’ or ‘presence bit’ which indicates if the address is to a segment in main memory or to a secondary-storage block. When a non-resident segment (p-bit is off) is accessed, an interrupt occurs to load the segment from secondary storage at the given address, or if the address itself is 0 then allocate a new block. In the latter case, the length field in the descriptor is used to allocate a segment of that length.