From: shearerje_at_comcast.net
Date: Sat Jan 31 2004 - 21:57:05 PST
Fine-Grained Mobility in the Emerald System (Jul et al, 1988) presents a very simple concept: Provide an environment in which objects can be migrated between processing nodes of a modest homogeneous local area network. That, however, is the last simple concept in this paper. An object may involve: a name, a data portion or “representation”, and an active portion. The data portion may involve deep data, some of which moves with the object and some which doesn’t. The active portion includes a set of operations, and process state information such as its stack. There is also a “concrete type object” that is the object’s code, “activation records” that track invocation of the object, and processor registers, all of which must be kept track of when an object moves. The paper discusses this challenge in the context of programmability, finding objects, moving objects, and overall system performance.
Programmability involves hiding the mobility issue from the developer when the developer doesn’t want to know, and exposing it when the developer wants control. For example, using a single-object model for passive objects, active objects, and pretty much everything else about the system means that the developer has only one model to work with and doesn’t need to worry about whether the scope of usage of an object will change radically in the future. On the other hand, the developer can specify (actually “request” is more accurate) that an object be located, moved, or fixed (anchored) to a specific node. The developer can also specify that certain deep objects always be moved with the target object.
Finding an object is a multi-phase search that involves: looking on the local node, looking on the last known node, following a chain of forwarding addresses, broadcasting a query to suspected nodes (I didn’t quite follow this part), broadcasting an all-points bulletin, and as a last resort directly interrogating any nodes that haven’t explicitly said they don’t have the desired object. Only very rarely does the search progress beyond the first two or three steps. The remainder are mostly a recovery mechanism for when the initial invocation attempt fails.
Moving an object is lots of fun, especially if it is a full-blown active object with deep data and calling structures that have elements pointing to other objects. The bulk of the paper focuses on what to move with the object to maximize overall performance and how to keep all the pointers correct, both from the object pointing outward and from other objects pointing at this one. In the end, the presented rational and methods for doing this seemed complex but reasonably clear - except for the part about finding and moving the activation records and processor registers. I think I’ll have to read that again (and again) before I get a clear picture of what’s going on there. There were also some subtleties in the garbage collection, particularly the interaction between the distributed collector and active processes, I would like to understand better.
The paper ended with a discussion of measured performance results. In general, local performance was favored over remote performance in the design and it shows in the measurements.
This archive was generated by hypermail 2.1.6 : Sat Jan 31 2004 - 21:57:12 PST