Paper evaluations for 04/27/00

John Michael U. Datuin (
Thu, 27 Apr 2000 08:24:02 -0700

The Emerald paper discusses Emerald which is an object-based, distributed system and language used in developing other systems. The points that the authors were emphasizing
is that Emerald supports fine-grained mobility, meaning that the lowest unit being an
object (not a process) can move to different nodes within the system to be executed
locally on a node for better performance. Objects move for reasons of balancing the
loads of nodes, failures, better communications with other objects, or to use something
unique on that node.

Emerald is different from other systems in that it is objects that migrate between
nodes, instead of processes. One key reason for going with objects is that they
are smaller than processes, since a process may consist of many objects. Also,
there is typically less overhead when moving an object as opposed to a process.
In addition, objects are mainly self-contained, where as in a process it may
be difficult to find all its components and shared structures before it can be

Another key point the authors stated is that Emerald already contains language
support for mobility. This makes it easier for the programmer to to write programs
that take advantage of mobility.

There were a few things that weren't clear in this paper. One is the nature of
an Emerald process whose invocation stack is distributed across several
nodes. How exactly does the system handle such a case in terms of
keeping track of the objects' executions and how and where do they
return after execution. I know they mentioned such notions as call-by-move
or call-by-visit, but when object B returns before object A, how is the process
affected? Another is the idea of protection. After reading several papers about
different systems and their schemes for protection, this paper wasn't explicit
in their description of protection between processes and objects (even though
objects themselves are self-contained, and that Emerald uses shared memory).


The Grapevine paper was a different paper than the previous ones we read.
The paper discussed the Grapevine system which is a distributed system
that is replicated (well parts of it) across several nodes. It main uses was
for e-mail, where huge lists of users and computers were maintained across
several computers in the system.

The main ideas presented in the paper were the 2 services provided by
Grapevine: message service and registration service. Also they mentioned
the use of the GrapevineUser package which code that provides services for
client programs.

I guess that since Grapevine was built on top of a Pilot system (which I
believed the authors mentioned), then the issues of protection and
sharing weren't really discussed in this paper. Well, sharing of messages
was discussed, but not really sharing of resources. The notion of inboxes
was also described.

The paper was really concerned about the operation of the Grapevine system,
by adding blurbs of ideas in designing a distributed system. The paper discussed
about load problems and how they dealt with it, and how one should maybe
use this in handling load issues on a new system. They did this similarly with
their problems of link failures, bad hardware, too small of disk space, unnecessary
replication of data, and so on.

An interesting piece of the paper was in the tools used to monitor and debug
the system. Using the tools remotely (the viticulturist's entrance) saved them
the grief of having to send a person to the actual site (which may be far
away) to fix some problem.