In a typical Legion system, the number of objects is expected to be orders of magnitude larger than the number of available processors. Thus, it would be unreasonable for our design to require an active process for every object in the system, although this would be the naive approach to implementing the disjoint address space model.1 To address this issue Legion objects are persistent, and alternate between two different states, active or inert. When an object is active, it is running as a process on a Legion host and it can be accessed via an object address. When an object is inert, it exists in persistent storage that is controlled by a Legion vault object (see Vault Objects), is described by an object persistence representation (OPR), and can be located using an object persistence address (OPA). Throughout their lifetime, objects can be moved between active and inert states by other Legion objects.
An OPR is associated with each Legion object and is used to store an object's persistent state (see Figure 27). Legion objects implement an internal saveState() method, which enables them to store persistent state into their OPR before becoming inert, and an internal restoreState() method, which is called immediately after reactivation to recover needed state from the OPR. Through the use of these object-internal mechanisms, in cooperation with system management of OPRs, objects are given the opportunity to preserver their state when they are migrated between hosts.
The OPA of an inert object is analogous to the OA of an active object. Objects use their OPA to gain direct access to their OPR. Typically, an OPA will be a file name (or a set of file names), and will necessarily only be meaningful to the Legion vault that controls the named OPR and to the object with which the OPA is associated.
|Figure 27: Storage of an object's persistant state|
|A Legion object has direct access to its persistent state, termed its
object persistence representation, or OPR. The location of an object's OPR
is called the object persistence address, or OPA.
1. Legion does not specify that each object will necessarily have its own process. Our current implementation has one process per active object, but future alternative implementations may have the ability to multiplex objects to processes. However, even assuming multiple objects per process, we expect the number of objects to exceed the ability of the system to support active processes. back
Back to Developer Manual Table of Contents