Fine-Grained Mobility in the Emerald System
Authors: Eric Jul, Henry Levy, Norman Hutchinson, and Andrew Black
Notes by Alfred Landrum.
Revised by Joe Lee, March 1999
Overview & Goals:
- Emerald is a language and system designed for constructing distributed programs
- fine-grained mobility - the authors refer to the fact that small data objects as well as
whole process objects can be moved from one node to another
- performance on par with regular procedure calls in the local case and with RPC in the
remote case
- The compiler will generate different implementations of an object
- Analysis of the object and hints from the programmer are used to decide which implementation is used
- Assumed setup is a LAN with a modest number (e.g. 100) of nodes
Object implementation
- All emerald objects have:
- a unique network-wide name
- a representation
- a set of operations (methods)
- an optional process
- an object that contains a process is an active structure. those that do not are passive structures)
- active objects make invocations to other objects.
- Global objects
- moved independently
- can be invoked by objects not known at compile time
- heap allocated
- invocation may require a remote invocation
- Local objects
- completely contained within another object
- cannot move independantly
- heap allocated
- invocations implemented via local procedure call or inline code
- Direct Objects
- a local object with a data area allocated directly in the representation of the enclosing object
- used mainly for simple objects whose organization can be deduced at compile time
Finding Objects
- The run-time system must keep track of objects or at least be able to find them when needed.
- Emerald uses a "forwarding address scheme
- Each node has a hash table which records entrys for remote objects that have a
local reference, and local objects for which a remote reference exists
- If an object has moved, its reference will be a forwarding address of the form <timestamp, node>.
- When an object must be found over the network, the kernel follows the forwarding addresses
(updating its local reference at the same time) until the object is found. If its not,
then a broadcast protocol is used.
Moving Objects
- Data Objects
- Emerald builds a message and xmits it to destination node
- Message contains:
- possible pointers to local and global objects
- translation information (to aid destination kernel in mapping location-dependant addresses)
- ODIs, forwarding addresses, and address of descriptor for global object pointers
- Data areas and addresses for local objects
- Upon receiption of message:
- kernel allocates space for moved objects
- kernel copies data into allocated space
- builds a translation table that maps original address into new address
- Object descriptors are located using ODIs or created where necessary
- kernel locates templates and updates pointers using translation table
- Process Activation Records
- maintain a list of activation records executing in each object
- on invocation, space is left for links and activation record is marked as "not linked"
- when a process is preempted, its activation stack is searched for "not linked" record, and these are then linked to the ovjet descriptors of their respective objects
- an operation must unlink its activation record when it terminates
- Processor Registers
- each invocation saves in it's activation record a copy of registers that it will modify
- the kernel sends a copy of the registers used in an invocation along with the moving activation record
- the kernel scans the invocation stack looking for saved registers
- on the destination note, the registers are modified using the translation table and stored with the newly created stack segment
Garbage collection
- Local collector:
- mark and sweep
- independent of other nodes
- can run any time
- Distributed collector:
- modified mark and sweep
- messages used to propegate mark and sweep algorithm to other nodes
- deals with node crashes (?)
- can run concurrently with executing processes (?)
Questions
- How good was the decision to let the compiler choose the implementation for an object?
Wouldnt a programmer always want to specify how an object should be
constructed?