From: Gail Rahn (grahn_at_cs.washington.edu)
Date: Sat Feb 14 2004 - 17:44:31 PST
Review of "Machine-Independent Virtual Memory Management ..." by Rashid et
al
The paper describes the virtual-memory management structure in Mach and
experiences gained form porting Mach to various hardware architectures. The
key to porting Mach is its separation of software memory management from
supportign hardware devices. The authors make frequent mention that Mach
contains only one pair of files (source code and header) that are aware of
memory-management hardware. All the rest of Mach's virtual memory
implementation consists of hardware-independent data structures and
algorithms. Portability was an early design goal of the Mach OS. Mach is
able to improve system performance without sacrificing portability - the
hardware-independent memory management system works as fast as
hardware-dependent systems.
Mach supports large address spaces, copy-on-write virtual copying,
read-write memory sharing, memory-mapped files and user-provided
backing-store and pagers.
Mach makes a few abstractions: tasks, threads, ports, messages and memory
objects. A memory object is a typed collection of data. It is managed by a
server (the kernel). Memory objects can be mapped into the address spaces of
tasks. Mach integrates memory management with message-passing communication
between tasks and a server (the kernel). The message-passing allows large
amounts of data, even files and address spaces, to be passed in a single
message and remapped between tasks.
Tasks can create and manage memory objects. Tasks can also set the
protection and interitance states of virtual memory regions. Memory can be
shared between a task and its children by altering the inheritance status of
a region of virtual memory. Inheritance is set as "shared", "copy" or
"none". Copy-on-write is permitted between the virtual memory of tasks.
In Mach, physical memory is considered a cache for the contents of virtual
memory objects. In a table indexed by physical page number (where page size
is a boot-time constant), information about physical pages is maintained. A
page entry in the table can be linked into a memory.
Because virtual memory is object-based, all pages associated with an object
are linked together in a "memory object list". "Memory allocation queues"
are maintained for freed, reclaimed and allocated pages of memory. Memory
objects have reference counts and are garbage-collected.
The kernel manages a task's virtual address space using an "address map", a
sorted doubly-linked list mapping ranges of virtual addresses to byte
offsets in memory objects. The address map structure is simple and
efficiently handles the most frequent memory operations.
To keep page faults and page-out operations outside of the kernel, memory
objects are associated with a managing task called a "pager". The kernel
communicates with the pager task to request data or notify of relevant
events. The kernel and the pager communicate to manage the object in
physical and virtual memory. Mach ships with basic pagers.
To handle shared memory, Mach implements "shadow objects", objects that are
placeholders for modified pages that originally belonged to another memory
object. Shadow objects generally contain only the modified pages of an
object, and rely on the memory object to obtain all the unmodified pages. A
sharing map manages the set of shared memory objects and their shadows.
Part of this paper that I didn't understand fully was the algorithm for
managing and garbage-collecting the chain of shadow objects that can be
created from repeatedly mapping memory objects between address spaces. Also,
at times the paper alluded to some kind of distributed memory management
implementation - talking about kernel as server and message-passing between
CPUs, I wasn't sure whether that was a reference to a standalone
multiprocessor system or some kind of network with multiple Mach nodes.
-------------
Gail Rahn
grahn_at_cs.washington.edu
This archive was generated by hypermail 2.1.6 : Sat Feb 14 2004 - 17:44:40 PST