Implementation of Distributed Objects in Emerald Eric Jul Bjarne Steensgaard Department of Computer Science University of Copenhagen Copenhagen, DEN MARK zyxwv 1 Introduction Emerald is a language and a system developed specifically for distributed computing using the object- oriented paradigm. In the following, I will mention several of important design issues that could be useful zyxwvut as a basis for further discussion. Thus my position on many issues is illustrated by describing a relevant Emerald feature rather than outright stating a posi- tion. 2 The Emerald language The Emerald language represents all data as ob- jects, provides facilities for object mobility for objects of all sizes, has an advanced t.ype system support- ing polymorphism, is strongly typed, contains parallel processes and monitored objects for synchronization[l, 2,3]. And it has actually been implemented. It runs on top of UNIX (4.2 BSD compatible versions) and native code generators exist for VAX, SUN 3. HP 9000/300's, and SUN SPARC. 3 The Emerald run-time kernel of interesting features: The Emerald run-time system[4] contains a number zyxwvut 0 Location independent remote procedure calls. Local procedure calls are executed zyxwvuts as efficiently as procedure calls in, say, C. Remote procedure calls use a faulting mechanism so that they fault to the run-time systems. The invoker or the in- vokee (or both) are allowed to move during the call. All objects on a single node are contained within a single address space. Protection is provided by the compiler (and so Emerald is a sin- gle language system). The main advantage is efficiency-local procedure calls are fast as is inter-object addressing. Full object and process migration including mi- gration of objects with multiple concurrently ex- ecuting processes inside-i.e., on-the-fly process mobility. 0 Immutable objects can be replicated through- out the network of Emerald nodes. Replication is performed by copying. When a non-resident immutable object is used it is copied to the node where it is used. System objects are handled as if they were language-level objects. For example, for the purpose of mobility, stacks are segmentjed and each segment is handled as a object, so that the general location and mobility mechanisms can be used. Another example is compiled code (immutable objects). System objects can be garbage collected as can language-level objects. Compiled code is dynamically loaded and dis- tributed. When an Emerald node receives a re- quest for running a program, the node uses the normal object locat,ion facility to find the re- quired code and to dynamically load it (possi- bly across the network). Because Emerald fully supports separate compilation, multiple compi- lation units may be loaded as a result of a single request. Shared code is loaded only once. Checkpointing of objects. An object can check- point itself on a node. Should that node subse- quently crash and get restarted, then the object will be reinstantiated based on the checkpoint image. The object can have a special "recovery" section that is called when an object has been recreated, so that the object can reestablish its invariant. Objects can also be checkpointed to other nodes (replication). Objects are divided into local and global objects. The local objects can only be called by objects residing on the same node. The compiler deter- mines which objects can safely be made local. Calling local objects are simpler and thus faster. The Emerald faulting garbage collec- tor Currently, we are developing a distributed garbage collector. It is of the mark-and-sweep kind, but it runs in parallel with Emerald processes by using an object faulting mechanism. Initially, almost nothing is marked. Should an Emerald process attempt to call an unmarked object, it will experience a zyxw garbage callectron fault much like a page fault. The collector zyx 4 0-8186-2265-2/91 $1.00 zyxwvutsrq 0 1991 IEEE -1