From: Brian Milnes (brianmilnes_at_qwest.net)
Date: Wed Feb 04 2004 - 15:14:27 PST
Fine Grained Mobility in the Emerald System - Jul, Levy, Hutchinson and
Black
Emerald is an operating system and object programming language designed to
test object mobility. Emerald's compiler selects a representation for an
object to allow it to be mobile and produces near C speed in function call.
An Emerald object has name, a representation, methods and an optional
process. The language has a concept of abstract type (signature) and
concrete type (representation of code and data). The motion primitives are
locate, move, fix, unfix and refix. The parameter passing is call by
reference with an optional move annotation. The stack of activation records
that makes up a process can be spread across multiple nodes.
The design of the system favors local speed. The processes are implemented
as light weight threads in a single shared memory address space and use both
strict typing and checks for protection. Global objects are moveable
independently, local objects must move with their global object and direct
objects are the native representations that can not move. Objects are
located using forwarding addresses. They have a global name and each node
keeps a hash to the objects with a forwarding reference counter. If the
object is unknown to the host a broadcast is used to track it down. This
seems to limit the cluster of machines to a local area network.
Objects have their pointers rewritten during move using compiler generated
templates which show which objects must be followed and where the pointers
are. The moving of an active object is much more complicated. The authors
perform a stack linking when each process is preempted and use this stack
link to move the required stack frames with the process. The registers of a
call must also be saved, fixed in type during the call, and moved to move
the calls. This should be a real disadvantage to a small register
architecture such as the Intel x86.
The system used mark and sweep garbage collectors: one for the local data
and a distributed one. Objects that move are marked with a bit so the local
collector leaves them intact. They sketch a distributed global garbage
collector which has to deal with allowing processes to run while garbage
collection progresses and hosts being unavailable. This seems the most
complicated piece of the design and I wonder if it was ever built.
They measure the performance first on basic operations such as remote
invocation with a reference parameter. They produce times in the 10-60 ms
range on a 10 Mb/s Ethernet which is pretty impressive.
This is a fascinating idea that would benefit from an Opal like single
shared address space. Moving processes is clearly a pretty useful idea and
generalizing RPC like this to move the data would be quite nice in most
systems that use RPC. However, the distributed garbage collection seems
complicated and is not built or benchmarked. Also the concepts miss the
replication of data which I suspect would be much more useful in the common
case.
This archive was generated by hypermail 2.1.6 : Wed Feb 04 2004 - 15:14:33 PST