ernet [76] systems had been in use at Xerox PARC for some
time, the industrial Ethernet standard had only recently been
completed and the first products were still in development.
To the extent that network applications existed at all, out
side of PARC, they were fairly primitive pointtopoint ap
plications such as FTP and email. UNIX did not yet support
a socket abstraction, and programming networked applica
tions required explicit message passing, which was difficult
and errorprone.
Eden was a research project proposed by a group of faculty
at the University of Washington (Guy Almes, Mike Fischer,
Helmut Golde, Ed Lazowska, and Jerre Noe). The project
received one of the first grants from what seemed even at the
time to be a very farsighted program at the National Sci
ence Foundation called Coordinated Experimental Research
(CER), a program that sought to build significant expertise
and infrastructure at a number of computer science depart
mentsaroundtheUnitedStates.ThestatedgoalofEdenwas
tosupport“integrateddistributedcomputing.”Whilenobody
had distributed systems at the time, it was clear that some
day in the future such systems would be commonplace, and
that programming them using existing paradigms would be
extremely difficult. The key insight of the Eden team was
to use objects—a computational model and technology that
was still controversial in both the operating system and the
programming language worlds at that time.
EdenwasitselfadescendantofHydra[108],thefatherofall
objectbased operating systems, developed by Bill Wulf and
his team at CarnegieMellon in the early 1970s. Guy Almes,
a junior faculty member at UW, had written his thesis on
Hydra at CMU [4], and brought those ideas to Washington.
The idea behind an objectbased distributed system was that
every resource in the network—a file, a mail message, a
printer, a compiler, a disk—would be an object. At the time
we looked on an object as nothing more than some data
bound together with program code that operated on that data
to achieve a specific goal, such as printing a file object, or
sending a mail message object, or running a compiler object
on a file object. The code was partitioned into what are now
referred to as methods for printing, sending, running, etc.,
but at the time we just thought of the code as a bunch of
proceduresthatimplementedoperationsontheobject’sdata.
The great thing about objects was that client programs could
use an object simply by invoking an operation in that object
and supplying appropriate parameters; they didn’t have to
concern themselves with how the object was implemented.
Thus, objects were a physical realization of Parnas’ princi
ple of information hiding [85]. The key insight behind dis
tributed objectbased computing was that the same principle
appliedtothelocationoftheobject:aclientcoulduseanob
ject without worrying about where that object was actually
located in the network, and two conceptually similar objects
(for example, two files) that were located in disparate places
might have completely different implementations. The Eden
system would take care of finding the object, managing the
remote communication, and invoking the right code, all in
visibly to the programmer.
Several other research projects also explored the distributed
object notion, notably Argus at MIT [71] and Clouds at
Georgia Tech [2]. Argus, as a language design, was essen
tially complete before the Emerald project started. Thus, Ar
gus was contemporary with Eden rather than with Emerald,
and indeed shared with Eden the idea that there were two
kinds of objects—“large” objects that were remotely acces
sible (and, in the case of Argus, transactional), and small
local objects (essentially, CLU objects). Some of the Clouds
ideas moved to Apollo Computer with the principals, and
appeared in the Apollo Domain system; there were several
visits between Apollo and Eden personnel.
This distributed object model is now the dominant paradigm
for Internet programming, whether it is Java/J2EE, Mi
crosoft .NET, CORBA, SOAP, or whatever. We take it for
granted. So it is hard to convey how controversial the dis
tributed object idea was in the early 1980s. People thought
that distributed objects would never work, would be way too
slow, and were just dumb. Objects had not yet been accepted
even in the nondistributed world: Simula was not main
stream,C++wouldnotbeinventedforsomeyears[100],and
Java wouldn’t appear for a decade and a half. Smalltalk had
just been released by PARC and was gathering a following
amongst computing “hippies,” but unless one had a Dorado,
it was not fast enough for “real” applications. Alan Born
ing, our colleague at Washington, had distributed copies of
the influential 1981 Smalltalk issue of Byte magazine, but in
our opinion, the focus of Smalltalk was on flexibility to the
detrimentofperformance.Smalltalk,althoughanimpressive
achievement, contributed to the view that poor performance
was inherent in objectoriented languages.
Emerald was a response to what we had learned from our
early experience with Eden and from other distributed ob
ject systems of that time. In fact, it was a followon to Eden
before Eden itself was finished. Before describing that ex
perience and its implications, we discuss the team and their
backgrounds and the beginnings of the project.
1.2 The People and the Beginning of Emerald
The Emerald group included four people:
1
• Andrew Black joined UW and the Eden project as a
Research Assistant Professor in November 1981. He had
a background in language design from his D.Phil. at
Oxford (under C.A.R. Hoare), including previous work
on concurrency and exception handling. Andrew brought
1
Another Ph.D. student, Carl Binding, participated in some of the initial
discussions with a view to being responsible for a reasonable GUI for
Emerald; he decided to do a different Ph.D., so the GUI of the Emerald
system remained quite primitive.

the perspective of a language designer to Eden, which
had been exclusively a “systems” project.
• Eric Jul came to UW as a Ph.D. student in September
1982 with a Master’s degree in Computer Science and
MathematicsfromtheUniversityofCopenhagen.Hehad
previous experience with Simula 67 [15, 41] and Con
current Pascal [29, 30] at the University of Copenhagen,
where he had ported Concurrent Pascal to an Intel 8080
based microcomputer [96], and also written a master’s
thesis [57] that described his implementation of a small
OSwhosedevicedriverswerewrittenentirelyinConcur
rent Pascal.
• Norm Hutchinson also came to UW in September 1982,
having graduated from the University of Calgary. He had
spent the previous summer on an NSERCfunded re
search appointment implementing a compiler for Simula
supervised by Graham Birtwistle, an author of SIMULA
Begin [15] and an object pioneer.
• Henry (Hank) Levy had spent a year at UW in 1980 on
leave from Digital Equipment Corp., where he had been
a member of the VAX design and implementation team.
While at UW he was part of the early Eden group and
also wrote an MS thesis on capabilitybased architec
tures,whicheventuallybecameaDigitalPressbook[70].
Hank rejoined UW as a Research Assistant Professor in
September 1983, and brought with him a lot of systems
building and architecture experience from DEC.
Shortly after his return to UW in 1983, Hank attended a
meeting of the Eden group in which Eric and Norm gave
talks on their work on the project. Although Hank was a
coauthor of the original Eden architecture paper [67], Hank
wasn’t up to date on the state of the Eden design and im
plementation, and hearing about it after being away for two
years gave him more perspective. Several things about the
waythesystemwasbuilt—andthewaythatitperformed—
did not seem right to him. After the meeting, Hank invited
Eric and Norm to a coffee shop on “the Ave”, the local name
for University Way NE, close by the UW campus.
At the meeting, the three of them discussed some of the
problems with Eden and the difficulties of programming
distributed applications. Hank listened to Eric’s and Norm’s
gripes about Eden, and then challenged them to describe
what they would do differently. Apparently finding their
proposals reasonable, Hank then asked, “Why don’t you do
it?”: thus the Emerald effort was born.
1.3 The Eden System
The problems with Eden identified at the coffee shop on the
Ave were common to several of the early distributed object
systems. Eden applications (that is, distributed applications
that spanned a localarea network) were written in the Eden
Programming Language (EPL) [21]— a version of Concur
rent Euclid [50] to which the Eden team had added support
for remote object invocation. However, that support was in
complete: while making a remote invocation in Eden was
much easier than sending a message in UNIX, it was still
a lot of work because the EPL programmer had to partici
pate in the implementation of remote invocations by writing
much of the necessary “scaffolding”. For example, at the in
voking end the programmer had to manually check a status
code after every remote invocation in case the remote opera
tion had failed. At the receiving end the programmer had to
set up a thread to wait on incoming messages, and then ex
plicitlyhandoffthemessagetoan(automaticallygenerated)
dispatcherroutinethatwouldunpackthearguments,execute
the call, and return the results. The reason for the limited
support for remote invocation was that, because none of the
Eden team had real experience with writing distributed ap
plications, we had not yet learned what support should be
provided. For example, it was not clear to us whether or not
each incoming call should be run in its own thread (pos
sibly leading to excessive resource contention), whether or
not all calls should run in the same thread (possibly leading
to deadlock), whether or not there should be a thread pool
of a bounded size (and if so, how to choose it), or whether
or not there was some other, more elegant solution that we
hadn’t yet thought of. So we left it to the application pro
grammer to build whatever invocation thread management
system seemed appropriate: EPL was partly a language, and
partly a kit of components. The result of this approach was
that there was no clear separation between the code of the
application and the scaffolding necessary to implement re
mote calls.
There was another problem with Eden that led directly to
the Emerald effort. While Eden provided the abstraction of
locationindependent invocation of mobile distributed ob
jects, the implementation of both objects and invocation
was heavyweight and costly. Essentially, an Eden object
was a full UNIX process that could send and receive mes
sages. The minimum size of an Eden object thus was about
200300kBytes—a substantial amount of memory in 1984.
This clearly precluded using Eden objects for implement
ing anything “small” such as a syntax tree node. Further
more, if two Eden objects were colocated on the same ma
chine, the invocation of one by the other would still require
interprocesscommunication,whichwouldtakehundredsof
milliseconds—slow even by the standards of the day. In
fact, things were even worse than that, because in our pro
totype the Eden “kernel” itself was another U NIX process,
so sending an invocation message would require two con
text switches even in the local case, and receiving the reply
another two. This meant that the cost of a single invocation
between two Eden objects located on the same machine was
close to half the cost of a remote call (137ms vs. 300ms).
The good news was that Eden objects enjoyed the benefits
of location independence: an object did not have to know
whether the target of an invocation was on the same com