From: Chuck Reeves (creeves_at_windows.microsoft.com)
Date: Wed Feb 04 2004 - 13:42:02 PST
The paper, "Fine-Grained Mobility in the Emerald System" describes an
object-based language and system called Emerald. It was written in 1988
by a number of researchers from the University of Washington. Emerald
was designed to support the construction of distributed programs on a
LAN. The elements of mobility in this system are objects, and as such
the approach supports relocation of smaller pieces of information, than
previous efforts (noted exception distributed smalltalk) which focused
on distribution of entire processes. The paper focuses on the language
constructs and provides a description of the run-time.
The language supports the idea of attaching member objects together
(through the Attach primitive) to create a object graph that requires a
single locality to function efficiently. Move, Locate, Fix, Unfix and
Refix primitives are also supported. Parameter passing as part of remote
invocation can be managed through the use of call-by-visit or
call-by-move semantics.
During execution, the run-time decomposes the stack into discrete
frames, each associated with a specific object. The system calls the
activation records. As object move about the system the information
associated with that activation record may need to move with it. Emerald
implements such a mechanism allowing different portions of the stack to
execute on different machines.
I thought the priorities used relative to performance were logical in
that optimizing the perf of remote calls at the sacrifice of local
execution performance would have little or no benefit.
The invocation forwarding mechanism used to locate objects from stale
references seemed simple and effective. I wonder how often the system,
falls back to doing a broadcast to find current object locations. Aren't
there some race conditions here in situations where objects are
frequently moving about the LAN?
I didn't really understand the optimizations surrounding moving
activation records. I would appreciate some coverage of this topic if
possible.
The description of the the garbage collection facilities were very well
written and made it easy to understand the optimizations that were made
to enable some parallelism relative to execution.
Chuck Reeves, creeves_at_microsoft.com
Microsoft | Windows | Directory Services
This archive was generated by hypermail 2.1.6 : Wed Feb 04 2004 - 13:42:09 PST