Group:
file system
Topic:
computer architecture
Topic:
device driver
Topic:
input/output by accessing a variable
Topic:
memory management by paging
Topic:
memory management by working sets
Topic:
memory management for programs and modules
Topic:
operating system kernel
Topic:
uniform reference to data
Topic:
virtualized hardware
| |
Summary
Virtual memory is needed whenever memory requirements exceed available memory and overlays are not general enough. The most important property of virtual memory is uniform reference for flexible data allocation. For instance virtual arrays are referenced like resident arrays: only in declarations are virtual arrays differentiated. If the operating system is developed for one application such as Bernstein's and Knobe's editing system, a simple scheme suffices. Bernstein and Knobe use three resident pages per user and a pool of freed pages. The scheme is effective since users free up pages as they use them.
Redell et al treats all file storage as virtual memory split into user definable "spaces". Spaces may in turn be split into a pool of sub-spaces. Users can advise the operating system for efficient memory usage. (cbb 5/80)
Subtopic: virtual memory 
| Quote: Oberon uses virtual memory for delayed loading, write protection, and simplified allocation for modules; no demand paging [»wirtN9_1989]
| | Quote: Unix virtual address space: shared, write-protected program text, non-shared data, and stack at high end [»ritcDM7_1978a]
|
Subtopic: resident vs. transient data
| Quote: Thoth has resident and transient teams of processes; transient teams swapped to secondary storage as needed [»cherDR2_1979]
| | QuoteRef: sammJE_1969 ;;576 "secondary" data does not require efficient storage
|
Subtopic: access control
| Quote: Helix access mode consists of type (read, write) and a lock (copy, original, exclusive);
|
Subtopic: memory-mapped files
| Quote: in Pilot, all file access goes through virtual memory, and files are the only backing store for virtual memory [»redeDD2_1980]
| | Quote: Pilot's kernel manages virtual memory access to special files and to preexisting, fixed-size normal files [»redeDD2_1980]
| | Quote: in Pilot, an allocation space is associated with a contiguous set of pages in a file; can be broken into subspaces [»redeDD2_1980]
| | Quote: Pilot swaps in the smallest space containing a page [»redeDD2_1980]
| | Quote: an Oberon writer initially creates an anonymous file; extension of memory since the disk space is reclaimed on system boot [»wirtN9_1989]
| | Quote: Multics treats files as segments in virtual memory; avoids file copies and overlay management, needs 'attach' mechanism [»dennPJ_1980]
|
Subtopic: sharing by memory map
| Quote: a Mach mapping descriptor can point to a sharing map for shared memory or directly to a memory object that is only shared by copy-on-write [»rashRF11_1986]
| | Quote: Mach tasks can directly map a memory object into another task's virtual memory; more efficient than Unix [»tevaA11_1989]
| | Quote: UNIX does not remap user buffers for I/O since requires page alignment and data would disappear after a write
| | Quote: Mach tasks form a tree structure defined by task creation; controls how memory is shared [»acceM6_1986]
|
Subtopic: versioned memory map
| Quote: PODUS uses a very large, sparse virtual-address space partitioned by version; each version contains object code and a binding table [»segaME3_1993]
|
Subtopic: copy-on-write
| Quote: instead of copy-on-write, allow low-level objects to steal heap structures from temporary variables [»simoAJ10_1998]
| | Quote: copy on write: don't allocate backing store for a copied page until write to it; lazy evaluation [»giffDK7_1985, OK]
| | Quote: a Unix fork operation is equivalent to a Mach task creating a child task with all memory copy-on-write
| | Quote: a task can mark regions of virtual memory as read-write, copy-on-write, or not inherited by child tasks
| | Quote: Helix access mode consists of type (read, write) and a lock (copy, original, exclusive);
| | Quote: Mach sends a large message as copy-on-write data via a temporary kernel address map [»acceM6_1986]
|
Subtopic: load on reference
| Quote: Oberon allocates imported modules but does not load them; delayed loading on first call by paging; supports larger systems [»wirtN9_1989]
|
Subtopic: garbage collection on virtual memory
| Quote: use virtual-memory hardware for efficient, copying garbage-collection; uniprocessors and shared-memory multiprocessors [»appeAW7_1988]
| | Quote: avoid paging while garbage collecting by cooperating with the virtual memory manager; use bookmarks to avoid virtual memory access; 5x faster under memory pressure [»hertM6_2005]
| | Quote: prior to eviction to disk; the BC garbage collector bookmarks references into the page and increments the target superpages' headers; allows collecting the heap without paging [»hertM6_2005]
|
Subtopic: managing virtual memory
| Quote: reduce bookkeeping by a cache of available sectors; since requests and releases occur at about the same rate [»bernN3_1977]
| | Quote: EDSYS uses a window size of about two disk sectors to insert, delete, and examine virtual memory [»bernN3_1977]
| | Quote: Oberon allocates memory for modules sequentially in virtual memory; Free releases the physical page but not the virtual page [»wirtN9_1989]
| | Quote: virtual memory should separate machine independent data from machine dependent data [»acceM6_1986]
| | Quote: Mach's virtual memory is built on hardware page validate, invalidate, and protect
| | Quote: Mach implements virtual memory with address maps, share maps, VM objects, and page structures
|
Related Topics
Group: file system (9 topics, 305 quotes)
Topic: computer architecture (46 items)
Topic: device driver (15 items)
Topic: input/output by accessing a variable (8 items)
Topic: memory management by paging (23 items)
Topic: memory management by working sets (18 items)
Topic: memory management for programs and modules (12 items)
Topic: operating system kernel (67 items)
Topic: uniform reference to data (34 items)
Topic: virtualized hardware
(5 items)
|
