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

• 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

• 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

• 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 entry’s 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? Wouldn’t a programmer always want to specify how an object should be constructed?