11.0 Object states

In a typical Legion system, the number of objects can be orders of magnitude larger than the number of available processors. It would be unreasonable to require an active process for each object in the system, although this would be the naive approach to implementing the disjoint address space model.1 To address this issue, Legion uses persistent objects that alternate between two different states, active or inert. When an object is active, it is running as a process on a Legion host and can be accessed via an object address (OA). When it is inert, it is in persistent storage that is controlled by a Legion vault object. In an inert state, an object can be described by an object persistence representation (OPR) and can be located using an object persistence address (OPA). Objects can be moved between active and inert states by other Legion objects.

Figure 26: Storage of an object's persistent 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.

Each Legion object is associated with an OPR. The OPR stores an object's persistent state (see Figure 26). 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.


1. Legion does not specify that each object will necessarily have its own process. Our current implementation generally 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.

Directory of Legion 1.8 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source

legion@Virginia.edu
http://legion.virginia.edu/