|
|
< Previous PageNext Page > |
The VM system used in Mac OS X is a descendent of Mach VM, which was created at Carnegie Mellon University in the 1980s. To a large extent, the fundamental design is the same, although some of the details are different, particularly when enhancing the VM system. It does, however, support the ability to request certain paging behavior through the use of universal page lists (UPLs). See “Universal Page Lists (UPLs)” for more information.
The design of Mach VM centers around the concept of physical memory being a cache for virtual memory.
At its highest level, Mach VM consists of address spaces and ways to manipulate the contents of those address spaces from outside the space. These address spaces are sparse and have a notion of protections to limit what tasks can access their contents.
At a lower level, the object level, virtual memory is seen as a collection of VM objects and memory objects, each with a particular owner and protections. These objects can be modified with object calls that are available both to the task and (via the back end of the VM) to the pagers.
Note: While memory objects and VM objects are closely related, the terms are not equivalent and should not be confused. .A VM object can be backed by one or more memory objects, which are, in turn, managed by a pager. A VM object may also be partially backed by other VM objects, as occurs in the case of shadow chains (described later in this section).
The VM object is internal to the virtual memory system, and includes basic information about accessing the memory. The memory object, by contrast, is provided by the pager. The contents of the memory associated with that memory object can be retrieved from disk or some other backing store by exchanging messages with the memory object. Implicitly, each VM object is associated with a given pager through its memory object.
VM objects are cached with system pages (RAM), which can be
any power of two multiple of the hardware page size. In the Mac
OS X kernel, system pages are the same size as hardware pages. Each
system page is represented in a given address space by a map entry. Each
map entry has its own protection and inheritance. A given map entry
can have an inheritance of shared
, copy
,
or none
. If a page is
marked shared
in a given
map, child tasks share this page for reading and writing. If a page
is marked copy
, child
tasks get a copy of this page (using copy-on-write). If a page is
marked none
, the child’s
page is left unallocated.
VM objects are managed by the machine-independent VM system,
with the underlying virtual to physical mappings handled by the
machine-dependent pmap
system. The pmap
system
actually handles page tables, translation lookaside buffers, segments,
and so on, depending on the design of the underlying hardware.
When a VM object is duplicated (for example,
the data pages from a process that has just called fork
),
a shadow object is created. A shadow object is initially
empty, and contains a reference to another object. When the contents
of a page are modified, the page is copied from the parent object
into the shadow object and then modified. When reading data from a
page, if that page exists in the shadow object, the page listed
in the shadow object is used. If the shadow object has no copy of
that page, the original object is consulted. A series of shadow
objects pointing to shadow objects or original objects is known
as a shadow chain.
Shadow chains can become arbitrarily long if an object is
heavily reused in a copy-on-write fashion. However, since fork
is
frequently followed by exec
,
which replaces all of the material being shadowed, long chains are
rare. Further, Mach automatically garbage collects shadow objects,
removing any intermediate shadow objects whose pages are no longer
referenced by any (nondefunct) shadow object. It is even possible
for the original object to be released if it no longer contains
pages that are relevant to the chain.
The VM calls available to an application include vm_map
and vm_allocate
,
which can be used to map file data or anonymous memory into the
address space. This is possible only because the address space is
initially sparse. In general, an application can either map a file into
its address space (through file mapping primitives, abstracted by
BSD) or it can map an object (after being passed a handle to that
object). In addition, a task can change the protections of the objects
in its address space and can share those objects with other tasks.
In addition to the mapping and allocation aspects of virtual memory, the VM system contains a number of other subsystems. These include the back end (pagers) and the shared memory subsystem. There are also other subsystems closely tied to VM, including the VM shared memory server. These are described in “Other VM and VM-Related Subsystems”.
< Previous PageNext Page > |
Last updated: 2006-11-07
|
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |