From: Nathan Dire (ndire_at_cs.washington.edu)
Date: Wed Jan 21 2004 - 17:35:49 PST
In "Sharing and Protection in a Single-Address-Space Operating System", Chase,
et al, present Opal, a single address space operating system for 64-bit
processors. With 64-bit systems becoming mainstream, there is a strong
argument for rethinking the design of modern operating systems. One major
design decision common to many systems is the notion of a separate address
space for each process.
With 64-bit architectures, there is an overwhelming amount of address space
available, such that separate 32-bit address spaces are no longer necessary to
accommodate the needs of programs. The single address space approach provides
many advantages since virtual addresses are valid for every process. When
communicating between processes, there is no need to convert data structures
since the pointers remain are valid for the receiver. In hardware, there is
no need for separate mappings for each process.
The single address space approach breaks the major memory protection barrier
in traditional systems, so Opal replaces it with segments. Since processes
run in the same address space in Opal, they are more like threads. The
execution context for threads is a protection domain which restricts access to
particular segments. For access control, Opal has capabilities to enable easy
sharing of resources among protection domains.
With capabilities and segments, Opal provides shared memory for interdomain
communication. In addition there are portals for transferring control between
domains, which are accessed through capabilities. This allows any thread to
access any code in the system--if so allowed. This breaks the traditional
model of static and private data in modules, so when linking in Opal, the
writable data must be separate from the executable code.
The implementation of Opal was done as a server running on the Mach
microkernel on a DEC Alpha-based system. While this ad hoc implementation
seemed to pay a price in performance, it compares well overall. One
difficulty with the Opal model is support Unix-style fork(), since in a global
address space, two execution contexts can't use the same virtual address.
I think this single address space approach is clearly beneficial, especially
for applications which share a significant amount of pointer-rich data (CAD
is mentioned). The major barrier is probably just the force of precedent with
the separate address space approach.
This archive was generated by hypermail 2.1.6 : Wed Jan 21 2004 - 20:15:17 PST