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

puter or across the network. The bad news was that if the
invoker and the target were on the same computer, the cost
was excessive.
Because of the high cost of Eden objects, both in terms of
memory consumption and execution time, another kind of
objectwasusedinEPLprograms—alightweightlanguage
levelobject,essentiallyaheapdatastructureasimplemented
in Concurrent Euclid. These objects were supported by
EPL’s runtime system. EPL’s languagelevel objects could
not be distributed, i.e., they existed within the address space
of a single Eden object (UNIX process) and could not be
referenced by, nor moved to, another Eden object. How
ever, “sending messages” between these EPL objects was
extremely fast, because they shared an address space and an
invocation was in essence a local procedure call.
The disparity in performance between local invocations of
EPL objects and Eden objects was huge—at least three
orders of magnitude.
2
This difference caused programmers
to limit their use of Eden objects to only those things that
theyfeltabsolutelyneededtobedistributed.Effectively,pro
grammers were using two different object semantics—one
for“local”objectsandonefor“remote”objects.Worse,they
had to decide a priori which was which, and in many cases,
neededtowritetwoimplementationsforasingleabstraction,
for example, a local queue and a distributed queue. In part,
thesetwodifferentkindsofobjectswereanaturaloutgrowth
of the two (unequal) thrusts of the Eden project: the primary
thrustwasimplementing“thesystem”;providingalanguage
on top was an afterthought that became a secondary goal
only after Andrew joined the project. However, in part the
two objectmodels were a reflection of the underlyingimple
mentation: there were good engineering reasons for the two
implementations of objects.
Thepresenceofthesetwodifferentobjectmodelswasoneof
the things that had bothered Hank in the Eden meeting that
he had attended. In their discussions, Eric, Norm and Hank
agreedthatwhilethetwoimplementationsmadesense,there
wasno goodreasonfor thisimplementationdetail tobevisi
bletotheprogrammer.Essentially,theywantedthelanguage
to have a single object abstraction for the programmer; it
would be left to the compiler to choose the most appropriate
implementation based on the way that the object was used.
1.4 From Eden to Oz
The result of the meeting on the Ave was an agreement be
tween Eric, Hank and Norm to meet on a regular basis to
discuss alternatives to Eden—a place that Hank christened
the land of Oz, after the locale of L. Frank Baum’s fantasy
story [9]. A memo Getting to Oz dated 27 April 1984 (refer
ence [69], included here as Appendix A) describes how the
discussionsaboutOzfirstfocusedonlowlevelkernelissues:
2
A local invocation in Eden took 137ms in October 1983, while a local
procedure call took less than 20μ s.
processes and scheduling, the use of address spaces, and so
on. This led to the realization that compiler technology was
necessary to get adequate performance: rather than calling
system service routines to perform dynamic typechecking
and to pack up data for network interchange, a smart com
piler could perform the checking statically and lay down the
data in memory in exactly the right format.
The memo continues:
It is interesting that up to this point our approach had
been mostly from the kernel level. We had discussed
address spaces, sharing, local and remote invocation,
and scheduling. However, we began to realize more
and more that the kernel issues were not at the heart
of the project. Eventually, we all agreed that language
design was the fundamental issue. Our kernel is just
a runtime system for the Oz language (called Toto)
and the interesting questions were the semantics sup
ported by Toto.
Eventually the name Toto was dropped; Hank thought that
it was necessary to have a “more serious” name for our
language if we wanted our work to be taken seriously. For
a time we used the name Jewel, but eventually settled on
Emerald, a name that had the right connotations of quality
and solidity but preserved our connection to the Land of
Oz. Moreover, the nickname for Seattle, where Emerald was
developed, is The Emerald City.
The Emerald project was both short and long. The core of
the language and the system, designed and implemented by
EricandNormfortheirdissertations,wascompletedinalit
tle over 3 years, starting with the initial coffeeshop meeting
in the autumn of 1983, and ending in February 1987 when
the last major piece of functionality, process mobility, was
fully implemented. However, this view neglects the consid
erableinfluenceoftheEdenprojectonEmerald,andthelong
period of refinement, improvement and derived work after
1987. Indeed, Niels Larsen’s PhD thesis on transactions in
Emerald was not completed until 2006 [66]. Figure 1 shows
some of the significant events in the larger Emerald project;
we will not discuss them now, but suggest that the reader
refer back to the figure when the chronology becomes con
fusing.
1.5 Terminology
A note on terminology may help clarify the remainder of
the paper. The terms message and message send, introduced
by Alan Kay to be consistent with the metaphor of an ob
ject as a little computer, were generally accepted in the
objectorientedlanguage community. However, we decided
not to adopt these terms: in the distributedsystems commu
nity, messages were things that were sent over networks be
tween real, not metaphorical computers. We preferred the
term operation for what Smalltalk (following Logo) called
a method, and we used the term operation invocation for