From: Sellakumaran Kanagarathnam (sellak_at_windows.microsoft.com)
Date: Wed Jan 14 2004 - 15:05:08 PST
The paper focuses on sharing and protection in the Opal, a
single-address-space operating system.
The initial trigger for this OS seems to have come from the advent of
64-bit address space architectures and the radical increase in the
amount of address space available because of that.
The authors' goal is to restructure operating systems in order to
improve the organization of both the system and its applications and in
particular to enhance sharing, simplify integration. Opal provides a
single global virtual address space that is shared by all procedures and
all data. Another design goal is to fully separate addressing and
protection. The fundamental principle of Opal is that the addresses
have unique interpretation all the time everywhere. The authors say that
many of the concepts in Opal are related to many previous systems and
they hope to demonstrate that recent advances in hardware, OS and
language technologies help in achieving the goals of previous systems
with out special purpose hardware, without loss of protection or
performance and without requiring a single type-safe language.
The authors discuss the single address space approach. Here the review
the advantages and disadvantages of multiple-address-space approach
(advantages: increased address space, provide hard memory protection
boundaries, easy cleanup on exit; disadvantages: obstacles to efficient
cooperation between protected application components - pointer based
information is not easily shared, stored or transmitted).
Private-address-space systems force poor tradeoffs between protection,
performance and integration. In single-address-space model, the system
rather than the applications coordinates the address bindings. All
virtual address space is treated as a global resource controlled by OS.
The authors state the advantages of private spaces will not be lost.
Protection domains are decoupled from other concepts in process. Opal
has no conventional programs and has procedures residing in shared
address space. A single-address-space system on one node can be
extended to include network-wide data and persistent data not in active
use. This helps reduce the frequency with which data conversion
mechanism (marshalling and translation) needs to be applied.
The next section defines the fundamental Opal mechanisms / facilities
that are intended to be building blocks for building languages and
runtime environments.
The units of storage allocation and protection are segments (contiguous
extent of virtual pages). The virtual address of a segment is a
permanent attribute and the smallest possible segment is one page. The
units of execution are threads. A protection domain is an execution
context for threads, restricting their access to a specific set of
segments at a particular instant in time. The Opal philosophy is that
storage allocation, protection and reclamation should be coarse grained
at the operating system level. Access control is provided by
capabilities. Attaching and detaching segments to the protection
domain are possible given the segment capability.
For interdomain communications (communication between threads) Opal
domains can create portals. Portals can be used to implement servers or
protected objects. A portal is an entry point to a domain uniquely
identified by portalID. Proxies on the client side and guards on the
server side explain the support that can be built above the basic Opal
facility-portals. Threads are allowed to create child domains.
While essentials of linking and executing code is the same in Opal and
conventional systems and sharing and dynamic use of code modules is easy
in shared address space, the support of private data in shared modules
is trickier (In Opal, instances of private static data must exist at
different virtual addresses).
Explicit reference counting is used for storage management (with the
help of attach and detach). Resource groups support accounting and bulk
deletes of unreleased resources. Opal runtime package retains a current
resource group for each thread and passes a capability for that group as
a hidden argument on server calls. Accounting charges flow up the tree
of resource groups and deletion privileges extend down the tree.
The next section talks about implementing an Opal Prototype using Mach
Microkernel. The authors talk about run time package, the Opal server,
persistence & recoverability and linking (resolve and refine utilities).
The next section talks about applications and performance where they
describe the Boeing CAD system. The authors present mediators to
facilitate tools interaction (UNIX style independence and tool
interactions was mentioned as a goal). Events are using to accommodate
this. The authors try to compare the cost of an Opal cross-domain call
(133 micro sec) with the cross-address space calls in Mach (88 micro
sec).
The authors then list the issues for the single-address-space approach
(virtual contiguity, conserving address space, UNIX-style fork, data
copying and copy-on-write). They conclude that the tradeoffs of the
single-address-space model are reasonable, given sufficient hardware
address space.
The authors then list down the relations to previous work.
1) Multics [1968] and other segmented systems [1988,1990]
2) Cedar [1986] and Pilot [1980] (these systems support a single
virtual address space in which all applications execute)
3) Capability based Architectures [1974,1981, 1984]
4) Object based operating systems and languages [Hydra-1975, 1985,
1983]
5) Monads [1992 and 1985] (these systems use a large 60-bit shared
virtual address space that includes persistent data and spans a local
network).
6) Psyche and Hemlock [1990]
7) Swizzling [1984] (is a method of simulating a large address
space on smaller-address hardware by translating pointers from short
inform to long outform or vice versa)
The authors believe that Opal is significant because it exploits modern
64-bit processors to meet the goals of previous systems in a way that is
simple, general and efficient. It requires no special hardware.
This paper is neatly organized and it tries to focus on protection and
sharing in Opal. Even though the paper is lengthy, I think that many of
the information in the paper are useful. I liked that it had two
separate sections for discussing the issues with this
single-address-space approach and the relation to previous work. I
think that there are enough details in the paper to understand the ideas
behind Opal and its construction. Proxy package explains the power and
usage of portals and also sets the expectations on the power of other
Opal abstractions in a similar way.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 15:05:16 PST