From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Feb 04 2004 - 17:35:09 PST
Emerald is a distributed object-based language and a system for
supporting the language. While there had been research into process
migration before, this appears to be the first paper describing a
system with fine-grained mobility control; specifically, one that
allows individual objects to be moved from node to node. The
authors claim that this additional level of control allows
improved invocation performance, garbage collection, and (obviously)
data movement.
My impressions within the first couple pages related to Java. I
was wondering how close Java's RMI came to doing what was described
here. Most people think of RMI (Remote Method Invocation) as only
being an RPC tool, but I believe it can also be used to actually
move objects (with restrictions around what kind of objects) from
server to server. My other thought around Java is that there is a
work being done within J2EE around making deployment easy, more
configurable, and more flexible. My first impression of this work
is that it appears to be an example of dynamic redeployment, or
redeployment that doesn't require bringing down a service.
One of the goals of Emerald was to have reasonably fast invocation
times when the object is local. The paper explains that many
existing process migration systems take on the order of
milliseconds or tens of milliseconds for local calls. Another
goal of Emerald was location transparency of the objects to the
developer. By designing a smart compiler to determine the "needs
of each object and generating an appropriate implementation" the
language allows the programmer to be free of such concerns.
Emerald objects are described to have a unique name, a
representation (aka properties?), operations (or methods?), and
an optional process (this is where I got a little confused --
at first I thought operations included the process to execute the
operation, but this may be making a distinction between interfaces
and methods). Then the interesting twist (to me) was the absence
of a class/instance hierarchy -- that each object carries its own
code. This seems to make sense for a system designed for
mobility. However, while an object carries its own code,
identical objects can share the same code and no code is
transferred when an object is transferred. Instead, only the
object's process stack is transferred.
The paper enumerates the primitives for mobility, but what I
thought was especially interesting was how it dealt with
determining "how much to move", or (this is probably a gross
simplification, but...) how deep to copy. The "attached" keyword
demonstrates another advantage of building this system around a
language that can allow programmers to indicate what objects
should move with others. I also found the modified mark-and-
sweep garbage collection algorithm to be an interesting
adaptation of existing methods.
The authors also include a section of the paper to discuss how
objects are found, which I was wondering about from the start.
I was assuming there was some central registry that had to be
checked with each invocation (potentially with local caches)
and updated with each object move. Instead, they appear to
have used a much more efficient design based on forwarding
addresses with timestamps to determine the most recent one.
When an object is called on a node where it no longer exists,
a chain of forwarding links will eventually cause the runtime
to find the object, which will then return its direct location
to the caller piggybacked on the reply message.
This archive was generated by hypermail 2.1.6 : Wed Feb 04 2004 - 17:35:11 PST