Fine-grained mobility in the emerald system

• Authors: E. Jul;H. Levy;N. Hutchinson;A. Black
• Venue: SOSP '87 Proceedings of the eleventh ACM Symposium on Operating systems principles
• Year: 1987

The Emerald compiler analyzes object definitions and attempts to produce efficient implementations commensurate with the way in which objects are used. For example, an object that moves around the network will require a very general remote procedure call implementation; however, an object that is completely internal to that mobile object can be implemented using direct memory addressing and inline code or procedure calls.We wanted to achieve performance competitive with standard procedural languages in the local case and standard remote procedure call systems in the remote case. These goals are not trivial in a location-independent object-based environment. To meet them, we relied heavily on an appropriate choice of language semantics, a tight coupling between the compiler and run-time kernel, and careful attention to implementation.As an example of Emerald's local performance, Table 1 shows execution times for several local Emerald operations executed on a Micro VAX II1. The “resident global invocation” time is for a global object (i.e., one that can move around the network) when invoked by another object resident on the same node. By comparison, other object-based distributed systems are typically over 100 times slower for local invocations of their most general objects [6, 1].The Emerald language uses call-by-object-reference parameter passing semantics for all invocations, local or remote. While call-by-object-reference is the natural semantics for object-based systems, it presents a potential performance problem in a distributed environment. When a remotely invoked object attempts to access its arguments, those accesses will typically require remote invocations. Because Emerald objects are mobile, it may be possible to avoid some of these remote references by moving argument objects to the site of a remote invocation. From this table we can compute the benefit of call-by-move for a simple argument object. For this simple argument object, the additional cost of call-by-move was 2 milliseconds while call-by-visit cost 6.4 milliseconds. These are computed by subtracting the time for a remote invocation with an argument reference that is local to the destination. The call-by-visit time includes sending the invocation message and the argument object, performing the remote invocation (which then invokes its argument), and returning the argument object with the reply. Had the argument been a reference to a remote object (i.e., had the object not been moved), the incremental cost would have been 30.8 milliseconds. These measurements are somewhat of a lower bound because the cost of moving an object depends on the complexity of the object and the types of objects it names.Emerald currently executes on a small network of MicroVAX IIs and has recently been ported to the SUN 32. We have concentrated on implementing fine-grained mobility in Emerald while minimizing its impact on local performance. This has presented significant problems; however, through the use of language support and a tightly-coupled compiler and kernel, we believe that our design has been successful in meeting both its conceptual and performance goals.