How to Use a Bit Virtual Address Space
Je rey S Chase Henry M Levy Miche Baker Harvey and Edward D Lazowska
Department of Computer Science and Engineering FR
University of Washington
Seattle WA
Technical Rep ort
Abstract
Most op erating systems execute programs in private address spaces communicating through messages
or les The traditional private address space mo del was develop ed for and bit architectures on
which virtual addresses are a scarce resource
The recent app earance of architectures with at bit virtual addressing op ens an opp ortunity to
reconsider our use of virtual address spaces In this pap er we argue for an alternative addressing mo del
in which all programs and data reside in a single global virtual address space shared by multiple protection
domains Hardware based memory protection exists within the single address space providing rewalls
as strong as in conventional systems
We explore the tradeo s in the use of a global virtual address space relative to the private address
space mo del We contend that a shared address space can eliminate obstacles to e cient sharing and
exchange of data structures that are inherent in private address space systems The shared address
space o ers advantages similar to some capability base d computer systems but can b e implemented
on standard page based hardware without the p erformance costs and restricted data mo del typical of
capability bas ed systems
We intro duce Opal an op erating system to supp ort this mo del on paged bit architectures The
key feature of Opal is a at virtual address space that includes data on long term storage and across the
network
Intro duction
The rapidly increasing demands of software b oth applications and op erating systems together with in
creasing VLSI densities have brought us to the verge of a ma jor architectural change the move from a
bit to a bit virtual address space This trend can b e seen for example in the architectures of the HP
PA RISC Lee and the IBM RS Groves Oehler The MIPS R MIP and Digital s
recently announced Alpha family Dobb erpuhl et al are the rst architectures with unsegmented bit
address spaces
Unlike the move from to bit addressing a bit address space could b e revolutionary instead of
evolutionary with resp ect to the way op erating systems and applications use virtual memory Consider that
bits can address a terabyte two orders of magnitude b eyond the primary and secondary storage capacity
of all but the largest systems to day More signi cantly a full bit address space consumed at the rate of
megabytes p er second will last for nearly years Such large address spaces eliminate the need to
reuse addresses in order to supply each executing program with su cient name space invalidating a basic
assumption that has driven op erating system design since the s
The purp ose of this pap er is not to argue in favor of the architectural change to bit addressing we
simply assume that wide address architectures will app ear indep endently of how op erating system designers
decide to use them Instead our purp ose is to argue that op erating systems should take advantage of these
wider addresses by supp orting a single global virtual address space that maps all data in the system The
This work is supp orted in part by the National Science Foundation under Grants No CCR CCR CCR
and CDA by the Washington Technology Center by the Bo eing Corp oration and by Digital Equipment
Corp oration through the Systems Research Center DECwest Engineering the External Research Program and the Graduate
Engineering Education Program
system could b e a distributed memory computer or even a large network though we do not explicitly
discuss distribution issues in this pap er
In this pap er we explore the costs and b ene ts of this mo del the uniform address model by comparing
and contrasting it with the memory addressing mo del used in most op erating systems to day the process
based model Both mo dels de ne the concepts of address space the virtual addresses used by an executing
pro cessor to name op erands in memory and protection domain an execution context that restricts the
1
pro cessor s access to memory They di er only in their view of the relationship b etween these concepts
Process based systems or private address space systems equate the notions of protection domain and
address space combining them into a single concept known as a process in Unix or Multics a task in
Mach and an actor in Chorus In these systems every protection domain has its own address space
Uniform address systems or single address space systems execute all protection domains in a common
paged virtual address space containing all data The notions of address space and protection domain
are fully indep endent
As an example of the uniform address mo del we intro duce Opal a distributed op erating system that we
are building An Opal protection domain is in many ways the analog of a Unix pro cess or Mach task for
example there is typically one protection domain p er executing application containing some private data
threads and RPC connections to other domains The di erence is that an Opal domain has a private set of
access privileges for globally addressable pages rather than a private virtual naming environment Domains
may grow shrink or overlap arbitrarily by sharing or tranferring page p ermissions among themselves Opal s
at virtual address space includes data on long term storage and across the network In general a given
piece of data app ears at a xed virtual address indep endent of where it is stored or which domains access it
No sp ecial hardware supp ort for Opal is assumed or required Our architectural assumptions are an
unsegmented paged virtual address space bit virtual addresses with or more meaningful bits
e cient sparse use of the address space supp ort for multiple protection domains that control access to
data on a page granularity and no constraints on virtual address usage within a protection domain These
conditions could b e met by simply extending the addressing widths on a conventional paged architecture with
a software loaded translation bu er such as the MIPS R We b elieve that Opal could run e ciently on
DEC Alpha and MIPS R pro cessors
Why a Single Address Space
The key prop erty of a uniform address system is that virtual addresses are context independent the
meaning of a virtual address is indep endent of the entity issuing that address We have noted else
where Koldinger et al that context indep endent addressing frees pro cessor hardware from the need
to supp ort multiple sets of address translations allowing optimizations in the memory system notably the
trouble free use of a virtually addressed data cache In the software context indep endent addressing sim
pli es the sharing storage and retrieval of data esp ecially structured data containing emb edded p ointers
It is this improved supp ort for sharing that we are concerned with in this pap er This section previews the
main p oints of our argument
Our notion of sharing is quite general sharing o ccurs whenever a domain uses data or code that is
created by some other domain By this de nition sharing is common Sharing can b e sequential as well as
concurrent so it encompasses data transfer from one domain to another through messages or les Distributed
communication and long term storage are sp ecial cases of sharing b etween domains in which the domains
are physically separated by a network or their lifetimes are disjoint
Pro cess based systems intertwine naming and protection in a way that limits their ability to supp ort
sharing e ciently The problem is that each domain cho oses addresses for shared data indep endently of
other domains in general this means that the pro ducer and consumer of data use names inconsistently
1
We also use the term protection domain informally to denote the collection of data that is accessible from such an execution
context or to refer to a pro cessor executing in the context
Section will show that these naming problems cause extra overheads when data is shared such as excessive
data copying and software p ointer translation Programs may b e structured to make unnecessary cross
domain RPC calls b ecause sharing is di cult to implement
A single address space system separates naming and protection simplifying sharing in two ways First
virtual addresses can b e passed b etween domains any byte of data can b e named with the same virtual
address by any protection domain that has p ermission to access it Second domains can imp ort data
containing emb edded virtual addresses without risk of a name con ict with other data already in use by the
domain These prop erties make it easier to implement sharing as direct sharing of a single copy of the data
Sharing and Trust
Improved supp ort for direct sharing is b ene cial even if there is no explicit interaction b etween protection
domains For example an Opal domain can dynamically attach to shared co de mo dules in any combination
without runtime linking Section More imp ortantly direct sharing can b ene t domains that are co op
erating in some way Why do protection domains need to co op erate or share data We generally think of
each domain as executing a self contained application but in fact there are several reasons why interacting
software comp onents might run in separate protection domains
Providing a service to multiple users Servers are protected from their clients to prevent a client from
interfering with service to other clients
Accessing a database shared by multiple users To ols for directly accessing a common database execute
with separate protection identities that re ect the access privileges of their users
Program continuity By de nition a protection domain cannot survive a system restart However a
new domain may b e created after a restart that picks up where an earlier one left o
Distribution By de nition a protection domain cannot span no des in a distributed system However
domains on di erent no des p erhaps executing di erent parts of the same application may interact
through message passing or distributed shared memory
Composing programs In most systems co de that is packaged as an executable program can b e executed
only by creating a new protection domain for it to run in If we want to join the output of one program
to the input of another we connect two domains with a mechanism such as a Unix pip e
Enforcing modularity A large application may b e decomp osed into multiple protection domains for
software engineering reasons e g to aid debugging by limiting the propagation of errors
All of these arrangements are familiar in to day s computing environments and all of them involve di erent
privilege and trust relationships b etween the co op erating domains Comp osed programs could b e fully
trusting if so they might just as well b e executed in the same protection domain which is di cult to
achieve in pro cess based systems but easy to achieve in Opal Partial trust relationships are also common
For example a server never trusts its clients but each client must trust the server to some degree A child
domain always trusts its parent though the parent never fully trusts the child Database to ols are mutually
trusting to the extent that their user s access privileges overlap
Opal provides several mechanisms to allow even untrusting domains to share a physical copy of data
safely readonly access sequential sharing using transfers of access p ermissions and system
enforced page level lo cking Domains may use concurrently shared pages in restricted ways validating the
data b efore use or relying on language level protection Variations of these mechanisms are useful when
there is partial trust Section outlines some of the p ossibilities
Current software and architectural trends motivate more creative use of direct sharing Data copying
and protection domain switches have increased in cost relative to integer p erformance on recent pro ces
sors Ousterhout Anderson et al b At the same time software systems are growing in complexity
encouraging decomp osition into multiple protection domains The recent move toward server structure d
microkernel op erating systems is one imp ortant example of this trend Also CAD systems and other data
mo deling applications are frequently structured as groups of co op erating database to ols
Related Work
Like much research in op erating systems the Opal pro ject is driven by improvements in hardware technology
Uniform address systems have b een built b efore on the claim of improved supp ort for sharing but these
systems su ered from the limitations of their hardware platforms Only now is hardware advancing to the
p oint that it is practical to organize a general purp ose op erating system in this way
Cedar Swinehart et al and its predecessor Pilot Redell et al used a single virtual address space
on hardware that supp orted only one protection domain These were viewed as single user systems b ecause
there was no hardware based memory protection b oth systems relied solely on defensive protection from
the name scoping and typ e rules of a sp ecial purp ose programming language Our prop osal generalizes this
mo del to multiple protection domains
The term uniform addressing was intro duced in Psyche Scott et al which also has a single virtual
address space shared by multiple protection domains Psyche uses co op erating protection domains primar
ily as a means of separating di erent comp onents of a single parallel application with di erent mo dels of
parallelism and di erent scheduling needs We are interested in more general sharing relationships leading
to some di erences in our system abstractions More imp ortantly we extend uniform addressing to encom
pass data on long term storage and across multiple autonomous no des in a network Psyche restricts its
address space to data in active use on a single computer partly b ecause the system runs in a bit address
space However most of the b ene ts claimed for context indep endent addressing in Opal apply equally to
non p ersistent storage in Psyche
Systems with segmented addressing e g Multics Daley Dennis have some of the prop erties of
uniform address systems The rst phase of address translation on segmented architectures concatenates a
global segment identi er with a segment o set yielding a long form address from a global virtual address
space The segment identi er is retrieved from one of a vector of segment registers asso ciated with the
current domain Domains de ne a lo cal view of p ortions of the global address space by overlaying global
segments into their private segment registers Segmented architectures supp ort uniform sharing in some
cases but with some or all of the following restrictions cross segment p ointers are not supp orted
multiple p ointer forms exist that must b e treated di erently by applications and application software
must co ordinate segment register usage to create an illusion of a single address space
The Hewlett Packard Precision Lee di ers from other segmented architectures in that it allows appli
cations to sp ecify long form virtual addresses directly Thus the Precision could supp ort a uniform address
op erating system However long form p ointer dereference requires a sequence of four instructions so most
software for the Precision uses segmented addressing
Most capability based architectures Organick Levy supp ort uniform sharing of data structures
However it is now p ossible to achieve these b ene ts using conventional page based hardware without the
problems common to capability based systems restricted data mo del p o or p erformance and
lack of supp ort for distribution
Organization of the Pap er
The remaining sections develop the argument more fully in the following way Section is a detailed treatment
of the obstacles to sharing in pro cess based systems and the costs of some p opular software workarounds
Section outlines the basic abstractions of Opal explains how Opal s uniform address mo del eliminates the
sharing problems of pro cess based systems and suggests some examples of how direct sharing can b e used
e ectively by software In Section we answer some common ob jections to uniform addressing That section
fo cuses on the apparent b ene ts of context dep endent addressing which are sacri ced in Opal and other
uniform address systems Section summarizes our conclusions
Sharing in Pro cess Based Systems
Most op erating systems in use to day are based on the traditional mo del of processes executing in private
virtual address spaces The pro cess mo del evolved at a time when address bits were in short supply and
programs were assumed to b e indep endent and comp eting for resources The purp ose of the op erating system
was seen as arranging for equitable sharing of physical resources while isolating each executing program from
its comp etitors In this environment private address spaces serve three purp oses
Contiguity Each pro cess sees an abstraction of a dedicated machine with a contiguous linear address
space
Isolation An executing program cannot even name data that do es not b elong to it since all names
are interpreted in the context of its private address map
Reclamation Storage reclamation is trivial from the p ersp ective of the op erating system when a
pro cess terminates its storage is reclaimed No p ointers to the data can exist outside of the terminating
pro cess
Despite these apparent b ene ts the multiple name spaces of pro cess based systems present inherent
obstacles to data sharing and co op eration b etween programs The problem is that a stored p ointer has
no meaning b eyond the b oundaries of the pro cess that stored it information containing p ointers is not
easily shared b ecause the p ointers may b e interpreted di erently by each pro cess that uses the data Data
structures are easily shared by threads in the same pro cess but not across pro cesses
In practice sharing of data structures can b e achieved in pro cess based systems with some additional
software overhead A pro cess can address shared data if it rst imports that data into its private naming
context To do this it allo cates a range from its virtual address space and attaches the data to the range in
some way A translation pro cedure then converts p ointer references in the shared data to virtual addresses
that are meaningful in the pro cess naming context Broadly this imp orting and translation of data can b e
done in two ways One is to make a private copy of the data and translate the p ointers in the copy leaving
the original undisturb ed The other is to map a single copy of the data into any pro cess that uses it and
interpret p ointers in software each time they are dereferenced This section highlights the weaknesses of
several common variations of these approaches For the moment we assume that the private address spaces
of pro cesses are in fact managed indep endently In the presence of sharing this is frequently not the case as
discussed in Section
Copy Time Translation
The standard technique for sharing data structures in pro cess based systems is to recursively linearize them
for exchange through a le pip e or message Herlihy Liskov This technique was originally develop ed
for gathering data into a message bu er marshaling but it has also b een used to represent data structures
on secondary storage pickling Pickles have b een used e ectively for self contained structures that are used
in their entirety e g a program reading a small private data base on startup Birrell et al
Linearizing has serious limitations as a general purp ose mechanism for translating data structures from
one address space to another Linearized data must b e packed by the sender and unpacked by the receiver
b oth must traverse and copy the entire structure Transmitted data is copied from as few as two times for
optimized lo cal RPC implementations Bershad et al to as many as four times or more for transmission
through Unix pip es les messages or so ckets Also there is no way to represent a p ointer to data outside
of the package thus it cannot b e used to store or transmit a fragment of a larger structure and a pro cess
cannot fetch pieces of a linearized data structure on demand
Reference Time Translation
One alternative to linearizing is to translate p ointers in shared or copied data at reference time The
p ointers in this case are not virtual addresses but are enco ded as p ointer surrogates de ned in some
external naming context and interpreted by software either the application itself or co de emitted by a sp ecial
purp ose compiler The simplest scheme is to represent p ointers as o sets into a le or memory segment
A variety of complex schemes for surrogates have b een develop ed using one or more levels of indirection
through mapping tables This approach is used by p ersistent ob ject stores Moss Hornick Zdonik
and commercial ob ject oriented database systems The p ointer indirection in these systems allows ob jects
to b e easily moved to a di erent part of the address space to compact storage or to improve clustering
prop erties
Reference time translation has a heavy runtime cost O set based p ointers can increase the cost of
2
dereference by as much as not including the cost of saving and restoring segment base p ointers For
some ob ject based schemes the p enalty is much higher Dep ending on the lo cality and frequency of surrogate
p ointer dereferences this can signi cantly impact execution time
Another problem with reference time translation of surrogates is that there are generally two forms for
stored p ointers forcing the application or language pro cessor to keep track of which form to exp ect on each
dereference A third p ointer form may b e needed to represent p ointers to data outside of whatever naming
context the surrogates are de ned in Examples include cross segment p ointers in a segmented architecture
or cross database p ointers in some p ersistent ob ject stores Co ckshot et al If there is no globally uniform
name space for p ointers the reference may b e quali ed by a symb olic name e g a le name Symb olic
names are designed for human consumption and are inappropriate for use as p ointers They need sp ecial
interpretation that is slow nonuniform and p ossibly incorrect since a human may change the
binding b eing unaware that a stored reference exists
Swizzling
Some systems that use surrogate p ointers attempt to reduce the cost of interpreting p ointers by caching
the result of a translation overwriting the surrogate in place with the virtual address This technique
called swizzling is based on the assumption that the cost of the translation can b e amortized across multiple
dereferences of the same p ointer Swizzling is usually managed by a runtime package It must b e integrated
with the programming language implementation to lo cate stored p ointers in the data
One problem with swizzling is that it forces each pro cess using the data to make a private copy since the
swizzled p ointers are sp eci c to a particular address space In most systems this means that each pro cess
will allo cate virtual backing store even for data that is never mo di ed Also if multiple programs have tight
interaction through the shared data say a design editor and a design checker in a CAD environment then
swizzling will incur runtime overhead to keep the copies consistent
Swizzling has other problems inherited from its ancestor overlays First swizzled p ointers must b e
unswizzled back into surrogates b efore data is passed outside of the pro cess b oundaries e g for co
herency tra c or committing up dates to a database This further increases runtime overhead and the
implementation must know how to translate p ointers in b oth directions The unswizzling is typically done
in yet another copy of the data to avoid unswizzling the p ointers in place and losing any additional b ene t
from the e ort exp ended to swizzle them Second virtual pages cannot b e reassigned to new data without
some means of ferreting out stale swizzled p ointers to the data that previously o ccupied those virtual pages
when a virtual page is reassigned every swizzled p ointer must b e revalidated b efore it can b e used again
It has recently b een suggested that a swizzling paging system could b e used to supp ort programs that
demand more than bits of address space as a software alternative to wide address hardware Wil
son Wilson prop oses a system that uses wide p ointers in a disk representation of the data swizzled to
2
The dereference sequence needs an add instruction as well as the usual two loads from memory Note that o set based
p ointers are di erent from the register displacement addressing universally used in RISC architectures The di erence
is that with o set based p ointers the displacements are not known statically
bit p ointers at page fault time so that only the narrow p ointers app ear in memory One problem with
this approach sometimes called eager swizzling is that it translates al l imp orted p ointers even those that
are never used Eager swizzling is also complicated by the need to swizzle p ointers whose targets have not
b een imp orted and therefore do not yet have virtual addresses assigned For this reason Wilson s approach
allo cates virtual pages not just for imp orted data but also for the targets of all imp orted p ointers This
increases the risk that virtual memory will b e lled forcing an exp ensive reassignment
Swizzling was designed to allow a single pro cess to access stored data structures with restricted usage
patterns It works well if the pro cess can establish a working set in memory and op erate on it indep endently
It is less e ective in cases involving concurrent sharing or signi cant I O activity
Summary
In pro cess based systems sharing of data structures b etween pro cesses requires p ointer translation from one
name space to another at imp ort time at reference time or on rst use There are three problems common
to these translation schemes they are complex and require supp ort from the language interpreter and or
the application itself they restrict the scop e of p ointers in shared data and translation and copying
have a signi cant runtime cost The translation cost may b e reduced by copying the data and translating
the p ointers in place but this wastes storage and incurs copying and coherency overhead In the next section
we argue that these problems can b e avoided in a uniform address system by using direct virtual addresses
as p ointers in shared data
We recognize that a direct virtual address may not b e the b est way to represent a reference particularly
if late binding of the reference is needed for some reason The intent of this section is to show that translation
schemes have a cost that is to o high to pay when late binding of references is not needed Furthermore
we claim that late binding can always b e achieved with one or more levels of p ointer indirection that the
underlying representation of a reference is always in terms of virtual addresses and that these more complex
schemes can also b ene t from uniform addressing
We have assumed until now that the private address spaces of pro cesses are managed indep endently as is
generally the case Pro cesses sharing data can avoid the cost and complexity of translation by co ordinating
their address space usage so that the sharing partners attach each shared page to the same virtual page
a reserved area of overlap in their otherwise indep endent name spaces Pointers within shared pages can
then b e represented as unenco ded virtual addresses For example virtual addresses can b e saved directly
in a mapp ed le if that le is always mapp ed at the same address by any program that uses it this is the
approach used by Camelot Eppinger to supp ort databases with p ointers in them
The problem with this solution is that the overlapping address ranges are negotiated ad hoc so naming
con icts will o ccur if sharing patterns are not known statically Furthermore the mix of shared and private
regions intro duces dangerous ambiguity If pro cess A stores a p ointer to private data into an area shared
with pro cess B not only is it imp ossible for B to arrange access to the target but it cannot even detect the
error it simply interprets the p ointer incorrectly We b elieve that this approach is basically correct but that
the system rather than the applications should co ordinate the address bindings in order to accommo date
dynamic sharing patterns in a uniform way This is the essence of the uniform address mo del
Sharing in a Uniform Address System
The fundamental problem with the pro cess based mo del is that it de nes a xed relationship b etween
naming and protection The mo del provides no means to create a protection domain without creating a new
name space so interacting software comp onents cannot b e placed in separate protection domains without
intro ducing nonuniform naming of shared data Furthermore executable co de typically is linked to assume
that it will execute in a private name space since there is also no way to create a new name space without
creating a new protection domain it is imp ossible to execute a program image without creating a new domain
for it to run in
Uniform address systems avoid these problems b ecause they view naming and protection as indep endent
Sharing is simpler and more e cient than in pro cess based systems b ecause separate protection domains
can address the same physical storage with the same names
In this section we illustrate these p oints by discussing some features of Opal a uniform address system
that we are designing The discussion fo cuses on Opal s memory addressing mo del particularly the notion of
virtual segments the relationship b etween segments and protection domains uniform addressing of p ersistent
storage and the treatment of co de mo dules We avoid other asp ects of the system such as execution
structures cross domain control transfers RPC and storage management
Protection Domains and Virtual Segments
An Opal protection domain is an execution context that controls access to pages in a global virtual address
space A domain identi er is part of the register state of every executing pro cessor and a pro cessor may
switch from one domain to another with a privileged instruction that loads a new domain identi er from
3
memory Each protection domain has some p ossibly empty subset of fread write executeg p ermission for
each virtual page Multiple pro cessors may b e executing concurrently in the same domain Any protection
domain may create a new protection domain attach co de and data to it and start threads in it Threads
in the same domain have the same protection identity
To simplify access control and virtual address assignment the global address space is partitioned into
virtual segments each comp osed of a variable numb er of contiguous virtual pages that contain related data
Opal segments are similar to segments in Multics and other segmented systems The key di erence is that
each Opal segment is named by a virtual address range that is assigned when the segment is created and
xed until it is destroyed An Opal segment cannot grow b eyond the address range allotted to it when it is
created The address ranges assigned to di erent segments are always disjoint and all memory references
use a fully quali ed at virtual address This means that stored p ointers in Opal have a globally unique
interpretation so any domain with su cient privilege can op erate on linked data structures in any segment
without name con icts or p ointer translation Pointer structures can also span segments so di erent access
controls can b e placed on di erent parts of a connected data structure
Before a domain can complete a memory reference to a segment it must establish access to it with an
explicit attach op eration A memory reference to an unattached segment is re ected back to the domain
as a segment fault to b e handled by a standard runtime package One way to resolve a segment fault is to
dynamically attach to the segment This might b e useful if the application is navigating a p ointer graph
spanning a large numb er of segments In simpler cases when an application can anticipate what storage
resources it needs segments can b e attached eagerly In this case segment faults are used to trap and rep ort
references to data outside of the application s established set of storage resources they serve as a rst line
of defense against unexp ected b ehavior or costly resource searches caused by a stray memory reference
Persistent Memory
A persistent segment continues to exist even when it is not attached to any domain A recoverable segment
is a p ersistent segment that is backed on nonvolatile storage and can survive system restarts All Opal
segments are p otentially p ersistent and recoverable The p olicies for managing p ersistence and recovery vary
according to a segment typ e and are b eyond the scop e of this pap er Reclamation is discussed in Section
Persistent virtual memory can b e viewed as a replacement for a traditional lesystem Recoverable
segments share many of the characteristics of mapp ed les The op erating system faults pages into memory
transparently on reference eliminating the programming cost and runtime overhead of copying read and
3
If you think of a protection domain as corresp onding to a value for the address space identi er ASID register in the
MIPS architecture you won t go wrong Translation bu er entries are tagged with the contents of this register when they are
created a load or store cannot hit a TB entry unless the entry s tag matches the current ASID in the pro cessor Despite its
name the ASID has little to do with address spaces
write calls Also the integration of le cache management with the virtual memory system avoids two level
caching problems such as double paging and unnecessary consumption of swap space Stonebraker
Since p ersistent segments are assigned virtual address ranges in the same way as other segments Opal
4
supp orts a true single level store with uniform addressing of data in long term storage A domain can name
a segment by the address of any piece of data that lies within it even if the segment is not yet attached In
essence this allows p ointers b etween les a le can b e mapp ed without sp ecifying a symb olic name simply
by dereferencing a p ointer A symb olic name space for data exists ab ove the shared virtual address space
to b e implemented by one or more name servers that asso ciate symb olic names with arbitrary p ointers
Co de Mo dules
Opal stores executable co de in p ersistent segments called modules that each contain a group of related
pro cedures Mo dules are indep endent of protection domains a mo dule can b e attached by multiple domains
and the domain of a thread is in no way determined by the mo dule that the thread is executing Mo dules
are also decoupled from the data they op erate on a given mo dule might b e called by di erent domains to
op erate on data in many di erent segments These prop erties distinguish Opal mo dules from the notion of
a realm in Psyche
A pure module is a mo dule that contains no self mo difying co de and makes no static assumptions
ab out the load address of any data that it op erates on unless that data is to b e shared by all users of the
mo dule In general we exp ect that mo dules will b e pure see Section Pure mo dules in Opal are
statically linked into the global address space Globally linked mo dules can b e attached to any protection
domain without risk of name con icts in the co de references b ecause each mo dule resides at a xed address
the same address in any domain
There are two distinct b ene ts from global linking of co de mo dules First domains can dynamically load
mo dules without the overhead of linking at runtime There is no need to know at domain creation time
what co de will run in the domain any domain can call any pro cedure it has access to simply by knowing
its address even if the co de was compiled after the domain was activated For example a domain can call
through pro cedure p ointers passed to it in shared data Dynamic loading is driven by ordinary page faults
Opal can avoid dynamic linking for pure mo dules b ecause its address space includes p ersistent memory in
uniform address systems without a single level store all mo dules must b e dynamically linked
The second b ene t of global linking is that pure mo dules may b e freely shared b etween domains Within
a no de only one copy of each pure mo dule is needed on disk and in memory even if many programs or
domains are executing it Mo dule grain co de sharing can substantially reduce storage demands and runtime
load latency and it is increasingly imp ortant as runtime packages implementing high level programming
abstractions e g for graphics and user interface supp ort continue to grow in size and p opularity and
traditional op erating system kernel functions e g thread management Anderson et al a migrate into
runtime packages
Of course globally linked mo dules must b e relinked if they contain references to some other mo dule that
has b een mo di ed However mo dules that have large numb ers of references to them tend to b e standard
runtime libraries that are mo di ed relatively rarely A level of indirection jump tables can b e used for
references to frequently mo di ed mo dules e g during debugging
Pure mo dules by de nition make no assumptions ab out what other mo dules are loaded with them in
a domain There is no distinction b etween a program and a mo dule Any accessible co de mo dule can b e
invoked with or without creating a fresh domain for it to run in Either the caller or callee may insist on a
new domain to protect itself from the other party if neither cares there is no need to create a protection
domain
4
Access to p ersistent memory in Opal is fully transparent though explicit op erations may b e used to commit or ush
mo di ed data in segments with strong failure recovery semantics
Using Shared Memory
Uniform addressing intro duces new p ossibilities for organizing software systems using variations on the
general theme of shared memory Shared memory can improve p erformance by reducing the need for explicit
cross domain communication Conventional wisdom says that shared memory compromises isolation but
we claim that some uses of shared memory are inherently no less safe than more exp ensive mechanisms for
co op eration Comp onents can limit their interaction by restricting the scop e of the shared region and the
way it is used Here are some interesting variations assuming di erent degrees of isolation and trust
Page Passing A segment is shared sequentially by detaching it from the sender and attaching it to
the receiver The receiver can validate the data b efore use
Enforced Locking Access to a concurrently shared segment is sequentialized through lo cking It
is most e cient to rely on voluntary compliance with lo cking proto cols implemented in the runtime
system but the system can also enforce lo cking at a coarse granularity by arbitrating page access
p ermissions within the segment A similar scheme is describ ed in Chang Mergen
Producer Consumer Data is passed through a segment that is writable by the pro ducer but readonly
to the consumer The pro ducer is fully isolated but the consumer trusts the pro ducer to comply with
usage and synchronization conventions
Argument Result A parent domain shares a segment with its child The parent leaves arbitrary data
structures in the shared segment as input to the child and collects the child s output from the shared
segment after the child domain is destroyed
Open Server Client domains have readonly access to a shared segment that is infrequently mo di ed
Clients up date the shared segment with protected calls to a privileged server domain with exclusive
write access to the segment The clients trust the server to maintain the integrity of the structure
Deities A privileged domain has direct access to segments attached to client domains that rely on
it for some service e g supp orting some asp ect of the programming environment The privileged
comp onent might b e a debugger an external paging server Young et al or a garbage collector or
transaction manager for data structures that span client domains
Soft Firewal ls A single application is structured as a group of partially trusting domains that concur
rently share some but not all of their segments to strike some useful balance b etween isolation and
p erformance This assumes that there are some clean comp onent b oundaries within the program
These uses of sharing could b e largely transparent to prop erly written application co de Shared data
can b e hidden b ehind a pro cedural abstraction just as if it were private to a separate server co op erating
domains would generally use the same mo dule to op erate on a given piece of shared data The mo dule must
b e reentrant but it can b e indep endent of whether or not the calling threads are executing from separate
protection domains
The Costs of Uniform Addressing
Up to this p oint we have argued the case for context indep endent virtual addressing of data with no
mention of the costs if any other than the need to pay for wide address hardware Our argument has
b een that a global addressing context leads to an unambiguous and consistent interpretation of addresses
facilitating sharing Also by enforcing a single mapping b etween virtual and physical addresses on each
pro cessor aliasing and homonyms are eliminated allowing trouble free use of a virtually addressed data
cache
In this section we explore the b ene ts of private address spaces that are sacri ced to uniform sharing in
Opal and other single address space systems Section listed some of these apparent b ene ts all of which
stem from context dep endent addressing in pro cess based systems The question we wish to answer is what
will we lose if we build our op erating systems with fully context indep endent addressing
Broadly context dep endent naming has two useful prop erties Saltzer
Free choice of names Within a context names can b e assigned freely without danger of con ict with
names used by other contexts assuming no sharing o ccurs
Retargetable name bindings It is sometimes useful for users to delib erately assign di erent interpreta
tions to the same name
This section discusses examples of how private address space systems take advantage of these prop erties
fo cusing on the lowest level of naming the virtual addressing level The goal is to defuse p otential ob jections
to uniform addressing by identifying sp eci c claimed b ene ts of context dependent addressing and arguing
one of the following for each one the context dep endent addressing is not useful context dep endent
addressing might b e useful but an acceptable or b etter alternative exists or context dep endent naming
is useful but virtual addresses are the wrong level to apply the context dep endence Our conclusion will b e
that all context dep endence should app ear at higher levels of naming interpreted by software e g relative
to the registers of a particular thread and mapp ed into a single context indep endent virtual address space
interpreted by the machine
Free Choice of Addresses
In a uniform address space programs are not fully free to select addresses for the data they create nor can
they statically determine what addresses will b e chosen by the system From the p ersp ective of ordinary
user level co de the e ect is that the address space app ears to b e sparse and noncontiguous not the neat
package familiar from pro cess based systems
The rst concern is that indexed memory structures e g ob jects or structs arrays and linear co de
sequences must b e stored so that they are virtually contiguous Our premise is that the system can always
nd a virtual address range that is large enough to store an indexed structure contiguously assuming that
the structure do es not grow b eyond some reasonable maximum size known in advance Consider that a
contiguous ten terabyte chunk consumes less than one millionth of a bit address space We anticipate
that there will b e no problem with utilization or fragmentation even if the address space spans a network
of up to no des A no de bit address space would provide terabytes of name space p er
no de plenty of ro om to allow for huge storage volumes or aggressive preallo cation of the address space
Although indexed structures must b e allo cated contiguously p ointers and branches b etween those struc
tures have no dep endency on their relative p ositions in the address space Thus the loss of complete contiguity
is generally invisible to programs written in high level languages However heap management packages must
tolerate noncontiguous expansion of the heap
Reclamation
A related question is the issue of reclaiming address space In pro cess based systems each protection domain
has a private naming context so all names in the context are trivially reclaimed when the domain is destroyed
i e the program exits In a global addressing context data may b e referenced by any domain so its lifetime
is no longer tied to the lifetime of any particular domain
In a single address space reclamation is only as complicated as the sharing patterns If no sharing takes
place as in pro cess based systems then reclamation is no more di cult than it was b efore the system
reclaims address space simply by rememb ering which address ranges were allo cated to which domains Thus
the reclamation issue should not b e viewed as a weakness of the single address space approach but rather
as a complication that stems from its strength supp ort for arbitrary sharing patterns
In Opal the op erating system do es not track cross segment references It merely provides ho oks to allow
servers and runtime packages that manage shared segments to plug in their own reclamation p olicies Our
prototyp e implements one p ossible segment server that places active and passive reference counts on each
segment and provides a means for clients to manipulate those reference counts in a protected way It is the
resp onsibility of co de in the clients the runtime package and or the language implementation to use those
reference counts appropriately If the clients do nothing then the resulting p olicy is exactly that of most
pro cess based systems a segment is deleted i it is unattached and there are no symb olic names for it in the
name server Of course clients may misuse the counts to prevent storage from ever b eing reclaimed this is
an accounting problem
This approach re ects our view that reclamation should continue to b e based on language level knowledge
of p ointer structures application level knowledge of usage patterns and deletion of data by explicit user
command The system only promises that domains cannot harm each other with reclamation errors unless
they are mutually trusting This do es not mean that we are punting the issue of reclamation we cling to
the b elief that supp ort for simple but useful sharing patterns can b e built relatively easily
Private Static Data References in Shared Co de
Uniform addressing leads us to restrict the use of certain addressing mo des in shared co de In Section
we intro duced the notion of a pure co de mo dule A pure mo dule is restricted in the mo des that it can use
to address its private data Data is private if it has separate instantiations for each caller of the mo dule
We are mostly concerned ab out references to private static data that is not allo cated from a heap or thread
stack sp eci cally global variables declared in the mo dule and linkage tables used for late binding of
external symb ols referenced by the mo dule As an example of the second case consider that di erent users
of a mo dule may want to use di erent implementations of an interface imp orted by the mo dule e g one
user may want a sp ecial pro ling version of the math library
In pro cess based systems private static data is typically addressed relative to the program counter or
with absolute virtual addresses statically linked into the mo dule These p c relative and absolute references
are e cient and easy for language pro cessors to implement They resolve correctly even if the co de is shared
b ecause each instantiation runs in a separate domain with a private address space But in a uniform address
system co de that names private data using these mo des is impure impure co de is not prohibited in Opal
but it has certain p erformance costs First impure co de cannot b e directly shared b ecause private data
references using those mo des in shared co de will always resolve to the same piece of data which is not what
was intended Second co de using absolute addresses for private data must also b e dynamically relo cated
b ecause each copy must b e loaded at a di erent virtual address
To make mo dules pure all private data references must b e expressed as an o set from a base register
whose value is passed in by the caller of the mo dule Indexing from a base register is the norm on some
architectures e g MIPS and generally has no additional cost assuming the o sets are statically known
However the di culty of managing base p ointers dep ends on the sharing granularity for co de mo dules
Many pro cess based systems such as BSD Unix allow only a single shared mo dule a complete executable
program to b e loaded into each pro cess If we were to make a similar restriction in Opal there would b e
only one base p ointer p er protection domain and the implementation would b e trivial But if we allow more
than one shared mo dule to b e loaded into each protection domain then each mo dule must have its own base
p ointer and each mo dule must retain in its private data the base p ointers for the mo dules that it calls
Base p ointers must b e saved and restored whenever control crosses mo dule b oundaries
Our conclusion is that in order to allow fully general sharing of co de mo dules in a uniform address system
we must limit the use of absolute and p c relative addressing and supp ort p er mo dule base p ointers This is
trivial in some languages e g ob ject oriented languages and more di cult in others e g C However once
we have paid this cost fully general sharing and dynamic loading of co de mo dules are achieved very easily
without dynamic linking In pro cess based systems comparable supp ort for shared libraries involves the same
restrictions on absolute addressing that we have made and even with those restrictions requires dynamic
linking and or indirect addressing through linkage tables e g for cross mo dule branches Sabatella
The Trouble With Fork
The Unix fork op eration is de ned to clone the parent pro cess execution context including its private
address space in the child pro cess The copy can b e mo di ed indep endently of the original hence the
cloning semantics of fork assume a private address space for each protection domain and so cannot b e
emulated in uniform address systems
We view fork as a historical artifact with little value even in pro cess based systems Previously there
were two reasons to treat a child pro cess as a cloned replica of the parent to create multiple asynchronous
pro cesses executing the same program e g to exploit parallelism or to overlap I O and to allow co de
from the parent to run in the context of the child so that it can initialize that context e g le descriptors
as a prelude to executing a new program in it The use of fork for asynchrony has b een sup erseded by the
thread abstraction which is b etter suited to the purp ose Also microkernel systems supply primitives to
initialize the execution context of a child domain without actually executing co de in the child this ability is
a prerequisite to implementing fork in a user level Unix server Thus the only reason to implement fork at
all is to supp ort existing Unix programs that use it This is not one of our research goals nor should it b e
a dominant concern for op erating systems in the future note that most Unix programs do not make direct
use of fork
We also note that fork is a source of complexity and ine ciency in Unix systems The ma jority of
the state cloned by a fork is not needed by the child inspiring e orts to improve p erformance by cloning
data lazily e g copy on write or avoiding the copy altogether e g the vfork primitive in BSD The
cloning semantics of fork also interfere with supp ort for threads McJones Swart
Opal replaces fork with primitives to create and destroy protection domains and initialize them by
attaching segments and installing RPC endp oints The parent domain starts a thread in the child by making
a cross domain call to it We b elieve that these mechanisms are su ciently general
Copying and Grafting
Earlier we argued that many instances of data copying can b e eliminated by de ning a uniform address
space In particular data can b e shared without the naming problems that may force unnecessary copying
Obviously not all instances of copying can b e eliminated Two closely related uses of copying remain
Messages Some instances of message passing could b e reformulated as unmapping the message from
the sender and remapping it in the receiver But if b oth domains need write access to the pages yet
must b e isolated from each other s changes then the data must b e copied For example data to b e
passed may reside on pages containing other data that must b e kept
Versions A piece of data may b e copied to create a new piece of data that starts as a clone of the
original but diverges from it in arbitrary ways
When data is copied p ointers into the old copy must b e translated if they are to p oint into the new copy
In particular internal p ointers within the copied data must b e translated Pointers are translated using one
of the schemes describ ed in Section
In a pro cess based system context dep endent addressing can sometimes b e used to avoid translating
p ointers in data copied from one pro cess to another The trick is to place the copied data into the same
virtual address range in the receiver pro cess as it o ccupied in the sender Of course it is then imp ossible
for either pro cess to name b oth the copy and the original For lack of a b etter term let us call this grafting
Grafting is not p ossible in uniform address systems since there is only one naming context the copy must
o ccupy di erent virtual addresses from the original and p ointers must b e handled sp ecially
Examples of grafting are rare in to day s systems although they do exist It is sometimes used to make
copies of statically linked self mo difying co de mo dules or copies of writable private data segments private
to shared co de mo dules that have b een initialized with p ointers In practice most copies of this typ e result
from fork which we have already disp ensed with
Copy On Write Optimizations
Uniform address systems have one additional di culty stemming from their inability to use the grafting
optimization describ ed ab ove A pro cess based system can lazily evaluate a grafting copy using copy on
write but a uniform address system copying the same data could not use copy on write This is b ecause the
p ointers in the data must b e translated b efore the receiver can even read the data copy on reference could
b e used but not copy on write
We emphasize that grafting copies are the only case where a pro cess based system could use copy on write
but a uniform address system could not It might app ear that copy on write is incompatible with uniform
addressing b ecause it intro duces aliasing in the form of multiple virtual mappings to the same physical
page But in fact copy on write intro duces only a restricted and b enign form of aliasing called readonly
aliasing Chao et al Readonly aliasing is a hidden optimization that neither violates the consistent
interpretation of p ointers nor interferes with the use of a virtually addressed data cache leaving intact the
b ene ts we claim for uniform addressing The problem intro duced by more general forms of aliasing is that
the aliases will have separate entries in a virtual cache and the cache hardware must keep these duplicate
entries consistent since they map to the same physical address This problem do es not o ccur with readonly
aliasing if a write to either virtual address o ccurs a new physical address is assigned to one of them
destroying the alias and restoring a unique mapping Thus the value of a cache line is never mo di ed in
a way that a ects the value of another cache line A more detailed discussion of the relationship b etween
uniform addressing and virtual data caches can b e found in Koldinger et al
Because readonly aliasing is harmless a uniform address system can use copy on write in every instance
that a pro cess based system can except when p ointers in the copied data must b e translated Most uses
of copy on write apart from fork in existing systems are to optimize message passing particularly to pass
large messages b etween I O servers e g le or memory servers and their clients In these cases the data
either contains no p ointers or it is opaque to the server Of course in this case the server may not need
to retain access to the data after it is passed so it might b e b etter to unmap it this is discouraged by the
pro cess based mo del b ecause it creates a hole in the server s linear address space
Summary
We conclude that the loss of context dep endent addressing is generally painless The only troubling use
of context dep endent addressing is to simplify copying as opp osed to physical sharing of data containing
p ointers But this requires tricky co ordination of address space usage grafting and we see no comp elling
examples of it
It is p ossible to construct a hybrid of the uniform address and pro cess based mo dels that allows some uses
of context dep endent addressing In fact our original prop osal for global addressing suggested that a shared
address space on bit architectures should b e implemented as a policy in microkernel op erating systems
which make no assumptions ab out virtual address space usage by protection domains Chase Levy
We are now pursuing the pure single address space mo del for two reasons First we b elieve that context
dep endent addressing intro duces a dangerous non uniformity to the system Once it is present programs
can no longer assume that a virtual address has the same meaning to another domain Second the p olicy
approach complicates the memory system hardware as well as the op erating system software For example
cache lines for virtual addresses with multiple interpretations must b e tagged
Conclusions
We have presented a mo del for a uniform address operating system called Opal The key prop erty of Opal
is a single at virtual address space encompassing all data in the system across the network and on long
term storage Multiple protection domains similar to processes in to day s systems co exist in this common
address space providing a basis for virtual memory protection Opal requires no sp ecial hardware supp ort
other than a su cient numb er of virtual address bits We have evaluated the costs and b ene ts of this
uniform address mo del relative to pro cess based memory mo dels
The primary advantage of the uniform address mo del over process based systems is improved supp ort for
sharing of linked data structures b etween protection domains We describ ed obstacles to sharing inherent
in the pro cess based mo del and the runtime overheads of the data copying and p ointer translation schemes
used to circumvent those obstacles In contrast to the pro cess based mo del Opal allows programs running
in separate protection domains to share or exchange data structures through shared memory regions les
p ersistent memory and messages without additional software overheads Opal co de libraries can b e
dynamically loaded and physically shared in a fully general way without runtime relinking The notion of
executing a program dissolves since any pro cedure call can in principle b e made to execute in a private
protection domain at the caller s discretion the input and output of the pro cedure program can b e arbitrary
linked data structures
The disadvantages of Opal relative to the pro cess based mo del are loss of the contiguous linear
addressing environment for executing programs inability to supp ort the Unix fork abstraction and
inability to graft data structures from one address space to another Also by cho osing an addressing
mo del that p ermits and encourages sharing the system must cop e with the di culty of managing that
sharing For example it is not always clear when data can b e deleted in a uniform address system However
we b elieve that existing approaches to reclamation e g based on language supp orted garbage collection
are applicable and that the system can always prevent untrusting programs from harming each other with
reclamation errors
Opal s goals are similar to those of earlier capability based systems but there are crucial di erences in
the way those goals are achieved Opal trades away the ne grained ob ject protection of capability systems
in favor of a coarser but more e cient page based protection mo del This mo del can b e implemented in
software on standard bit hardware and can b e extended to accommo date distribution
To summarize here are three ways of viewing the Opal pro ject
As another step in the trend of decoupling concepts that are traditional ly combined in the notion of a
process The original conception of a pro cess in Unix or Multics combined addressing protection
execution and communication everything having to do with the relationship b etween an executing
program and the rest of the system Unifying these ideas in a single abstraction was intuitively app eal
ing given the assumptions in practice at the time Since that time physical storage has abstracted to
virtual memory execution has abstracted to threads and communication has abstracted to p orts and
RPC endp oints We now prop ose that address spaces b e separated from pro cesses as well An Opal
domain is exactly a pro cess stripp ed of everything but its protection identity
As a means of combining the uniformity of capability based systems with the performance and gener
ality of process based systems Capability based computers were not widely accepted b ecause of their
complexity p erformance and restrictive ob ject oriented data mo del Opal strives for the same uniform
addressing of storage but like pro cess based systems its addressing mo del is based on e cient untyp ed
storage abstractions rather than ob jects
As one approach to reconciling current software and architectural trends Op erating systems and appli
cations are increasingly decomp osed into multiple co op erating protection domains At the same time
the trend in high p erformance computer architectures is to p enalize this decomp osition by increasing
the relative cost of co op eration b etween domains This is b ecause co op eration in to day s systems relies
on data copying and cross domain calls which are increasing in cost relative to integer p erformance
Our approach encourages new mechanisms for co op eration based on shared memory which will scale
with integer p erformance on next generation architectures
We are currently prototyping the ideas describ ed in this pap er In addition to serving as a short term
pro of of concept the prototyp e e ort has two imp ortant long term goals First we wish to explore the
e ect of a shared address space on existing op erating system abstractions and mechanisms For example
the presence of sharing a ects strategies for thread management pro cessor allo cation and synchronization
recent work in these areas has assumed that domains are self contained indep endent and comp eting A
broader research goal is to explore ways in which the shared address space can b e used to improve the
structure and p erformance of applications and the op erating system by identifying uses of sharing that are
safe and can b e handled e ciently
Acknowledgements
We would like to thank the many p eople in the op erating systems community who have discussed these ideas
with us singling out the following p eople for sp ecial thanks Mike Burrows Carla Ellis Norm Hutchinson
David Kotz Richard LaRowe Brian Marsh Marc Shapiro and John Wilkes Many p eople at the University
of Washington have made valuable contributions esp ecially David Kepp el Eric Koldinger Kevin Sullivan
Chandu Thekkath and John Zahorjan Thanks also to Richard Korry and Rob ert Henry of Tera Computer
References
Anderson et al a T E Anderson B N Bershad E D Lazowska and H M Levy Scheduler activations
E ective kernel supp ort of the user level management of parallelism In Proceedings of the th
Symposium on Operating System Principles pages Octob er
Anderson et al b T E Anderson H M Levy B N Bershad and E D Lazowska The interaction of
architecture and op erating system design In Proceedings of the Fourth Conference on Architectural
Support for Programming Languages and Operating Systems pages April
Bershad et al B Bershad T Anderson E Lazowska and H Levy Lightweight remote pro cedure call
ACM Transactions on Computer Systems February
Birrell et al A Birrell M Jones and E Wobb er A simple and e cient implementation for small
databases In Proceedings of the Eleventh ACM Symposium on Operating Systems Principles
pages Novemb er
Chang Mergen A Chang and M F Mergen Storage Architecture and Programming ACM
Transactions on Computer Systems February
Chao et al C Chao M Mackey and B Sears Mach on a virtually addressed cache architecture In
Usenix Mach Workshop Proceedings pages Octob er
Chase Levy J S Chase and H M Levy Supp orting co op eration on wide address computers Depart
ment of Computer Science and Engineering Technical Rep ort University of Washington
March
Co ckshot et al W P Co ckshot M P Atkinson and K J Chisholm Persistent ob ject management
system Software Practice and Experience January
Daley Dennis R C Daley and J B Dennis Virtual memory pro cesses and sharing in MULTICS
Communications of the ACM May
Dobb erpuhl et al D Dobb erpuhl R Witek R Allmon R Anglin D Bertucci S Britton L Chao
R Conrad D Dever B Gieseke S Hassoun G Ho eppner J Kowaleski K Kuchler M Ladd
M Leary L Madden E McLellan D Meyer J Montanaro D Priore V Ra jagopalan S Samu
drala and S Santhanam A mhz bit dual issue CMOS micropro cessor In International
Solid State Circuits Conference February
Eppinger J L Eppinger Virtual Memory Management for Transaction Processing Systems PhD
dissertation Carnegie Mellon University February CMU CS
Groves Oehler R D Groves and R Oehler RISC system pro cessor architecture In M Misra
editor IBM RISC System Technology pages International Business Machines
Herlihy Liskov M Herlihy and B Liskov A value transmission metho d for abstract data typ es ACM
Transactions on Programming Languages and Systems Octob er
Hornick Zdonik M F Hornick and S B Zdonik A shared segmented memory system for an ob ject
oriented database ACM Transactions on O ce Information Systems January
Koldinger et al E J Koldinger H M Levy J S Chase and S J Eggers The protection lo oka
side bu er E cient protection for single address space computers Technical Rep ort
University of Washington Department of Computer Science and Engineering Novemb er
Lee R B Lee Precision architecture IEEE Computer pages January
Levy H M Levy Capability Based Computer Systems Digital Press Bedford Massachusetts
McJones Swart P R McJones and G F Swart Evolving the Unix system interface to supp ort
multithreaded programs Technical Rep ort DEC Systems Research Center Septemb er
MIP MIPS Computer Systems Inc Sunnyvale CA MIPS R Microprocessor User s Manual rst
edition
Moss J E B Moss The Mneme p ersistent ob ject store COINS Technical Rep ort University
of Massachusetts at Amherst Octob er
Organick E I Organick A Programmer s View of the Intel System McGraw Hill
Ousterhout J K Ousterhout Why aren t op erating systems getting faster as fast as hardware In
Proceedings of the Summer USENIX Conference pages June
Redell et al D Redell Y Dalal T Horsley H Lauer W Lynch P McJones H Murray and S Purcell
Pilot An op erating system for a p ersonal computer Communications of the ACM
February
Sabatella M Sabatella Issues in shared library design In Proceedings of the Usenix Conference pages
June
Saltzer J H Saltzer Naming and binding of ob jects In R Bayer R M Graham and G Seegmuller
editors Operating Systems An Advanced Course Lecture Notes in Computer Science pages
Springer Verlag
Scott et al M L Scott T J LeBlanc and B D Marsh Multi mo del parallel programming in Psyche
In Proceedings of the Second ACM SIGPLAN Symposium on Principles and Practice of Paral lel
Programming pages March
Stonebraker M Stonebraker Op erating system supp ort for database management Communications of
the ACM July
Swinehart et al D Swinehart P Zellweger R Beach and R Hagmann A structural view of the Cedar
programming environment ACM Transactions on Programming Languages and Systems
Octob er
Wilson P R Wilson Pointer swizzling at page fault time E ciently supp orting huge address spaces on
standard hardware ACM SIGARCH Computer Architecture News June University
of Illinois at Chicago Technical Rep ort UIC EECS Decemb er
Young et al M Young A Tevanian R Rashid D Golub J Eppinger J Chew W Bolosky D Black
and R Baron The duality of memory and communication in the implementation of a mulitpro
cessor op erating system In Proceedings of the Eleventh ACM Symposium on Operating Systems
Principles pages Novemb er