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

Figure 1: Some significant events in the Emerald Project
message send. In some ways this was unfortunate: language
influences thought, and because we avoided the use of the
terms message and message send, it was many years before
some of us really understood the power of the messaging
metaphor.
Emerald used the term process in the same sense as Con
current Pascal and Concurrent Euclid. A process was light
in weight and was protected by the language implementa
tion rather than by an operating system address space; to
day the term thread is used to describe the same concept.
Similarly, Emerald used the term kernel in the same sense
as its predecessor languages: it meant the languagespecific
runtime support code that implemented object and process
creation and process scheduling, and translated lowerlevel
interrupts into operations on the language’s synchronization
primitives. Successor languages now often use the term Vir
tualMachineaboutsuchruntimesupport.Indeed,ifwecre
ated Emerald today, we would have used the term Emerald
Virtual Machine.
2. The Goals of Emerald
Beyond “Improving on Eden,” Emerald had a number of
specific goals.
• To implement a highperformance distributed object
oriented system. While the Eden experience had con
vinced us that objects were indeed a good abstraction
for writing distributed systems, it did nothing to dispel
doubts about the performance of distributed objects. We
believed that distributed objects could be made efficient
and wanted to demonstrate this efficiency goad by con
struction. Norm saw that by exploiting compiler technol
ogy, we could not only make runtime operations more
efficient, but could eliminate many of them altogether
(by moving the work to compile time). Eric was already
concerned with widearea distribution: even during the
planning phases of the project he was thinking of send
ingobjectsfromCopenhagentoSeattle,althoughthisdid
not become possible for several years citeFolmer93.
• Todemonstratehighperformanceobjects .Steppingback
from distributed objects, we were also concerned with
validating the ideas of objectoriented programming per
se. Smalltalk80 had created a lot of excitement about
the power and flexibility of objects, but there was also
a lot of skepticism about whether or not objects could
ever be made reasonably efficient. The failure of the In
tel iAPX 432 architecture [79] effort had, in the minds
of some people, reinforced the view that objects would