From: Greg Green (ggreen_at_cs.washington.edu)
Date: Tue Feb 03 2004 - 21:42:43 PST
This paper describes an Object Oriented language and runtime
implementation that allow process and object migration over a local
area network. Process migration allows for load sharing,
communications performance, availability, and reconfiguration. Object
migration allows easy message passing, better performance, and
simplified distributed garbage collection.
An emerald object consists of an network-wide name, a representation,
a set of operations, and optionally a process. There is no hierarchy,
so objects carry all of their own code. There is a corresponding
concrete type object on a node for each object that resides on that
node. The concrete data type can be retrieved from another node if one
doesn't exist on the current node.
The language has several primitives for object mobility. Locate, Move,
Fix, Unfix and Refix. Parameter passing is call-by-object-reference,
whether the object being called is local or remote. Because of the
mobility it may make sense to move the parameter objects along with
the remote call to save network traffic and increase performance.
Processes are implemented using a stack of activation
records. Portions of the activation record stacks are moved along with
the object. So a given thread can have it's stack of activation
records on many different nodes depending on it's execution trace.
Since good performance was a prime criteria, an emerald system runs in
a single address space with the processes being lightweight threads in
that address space. Finding objects is done by a forwarding and
timestamp process, instead of updating all nodes with references to
the objects whenever the object moves. Also whenever an object moves,
it's pointers need to be retranslated at the new node. This is done
using a template generated by the compiler that resides in the
concrete type object. This identifies the pointers.
Finally distributed garbage collection was described. The system was
not fully implemented when the paper was written, so the system
described may have changed. They used a mark and sweep algorithm for
local objects, and a modified mark and sweep for distributed objects.
This paper was quite surprising to me as I had never thought of moving
objects around on the network. Sun's jini system had code moving
around but was quite primitive compared to this. It made sense that a
new language was needed to implement the system. There was little
discussion about the language itself. I would have liked to know more.
One thing that struck me was that security was never mentioned. It
isn't easy for me to decide how that fits in. Could especially nasty
virus's or worms be devised? Or can it be made more secure?
-- Greg Green
This archive was generated by hypermail 2.1.6 : Tue Feb 03 2004 - 21:42:46 PST