Emerald and Grapevine

Mark Andrew SMITH (masmith@cs.ucsd.edu)
Wed, 26 Apr 2000 23:52:55 -0700 (PDT)


Emerald is an object based distributed replicated OS in which the object
abstraction is leveraged in order to provide object mobility across the
network to achieve performance gain. Unlike previous systems, the object
concept in this system is of small objects which can be moved about
quickly. Moving a process can be application-implemented, transparent, or
non-transparent. Moving a process (and perhaps data associated with that
process) achieves many benefits including load sharing, communications
performance, and utilizing specialized hardware on the network to match
process tasks. Unfortunately, process migration is difficult to implement.
Most OSes make assumptions about processes, so adding the capability to
relocate them requires changes throughout an OS which makes any
modification fragile. Also, it is expensive to copy process state between
nodes, this is mitigated by the idea of very small object migrations which
Emerald is attempting to provide. Also, in attempting to make local
invocation cheap, process migration becomes very complicated.


Grapevine is a message delivery system that was implemented several years
prior and reported about in "Grapevine: an exercise in distributed
computing." This paper is an update to the first paper in terms of lessons
learned and predictions made. Currently, Grapevine is running on 17
servers, had 4400 Users, 1500 groups, and 8500 messages/day. They found
that the system (intended to run with 10000 users and 30 servers, would
scale to spec, but not very far past. Some of the main things that would
not scale well were the registration servers, which were required to know
about every other registration server and mail server, and this took up
15k of space per server. Also, the resource locater does a linear search
on all servers to find the closest one. One thing that scaled very well
was that messages were shared and that pointers to that message were
placed in mailboxes. Some design mistakes included the automatic remailing
on messages when an inbox was removed (resulting in a flood of mail), and
that there was no feedback to users as to message status. The fact that
disk was so small resulted in all kinds of problems including deadlock. It
is interesting to note that although many "simple" fixes were proposed,
that very few were implmented due to the fact that the designers had
forgotten how they had written the code.