10.0 Implementation model

When a user asks a class object to create an instance on another host (Figure 7, step 1), the class must do the following

• Determine what kind of architecture the new host has,
• Contact the correct vault object to request persistent storage space,
• Assign the new object a LOID and an Object Persistent representation Address (OPA--see "Object states" in the Developer Manual for further information) (steps 2 and 3), and
• Contact the correct host object and ask it to start the new object on the host using a particular implementation object (step 4).

Figure 7 shows the different steps in the procedure. There are different implementation objects for different architectures, and each class maintains implementation objects for all of the architectures on which it might run its instances.

Figure 7: Legion object creation

When the class object asks the host object to start an instance, it includes, as a parameter of the create_instance() call, the LOID of the implementation object that shares the same architecture as the host (Figure 8, step 1).

Host object Beta must now find a copy of the appropriate implementation object, which is stored on its associated vault (Figure 8, step 2). It will therefore need to track down the implementation object's LOID on Alpha and make a binary copy of the object for its vault (step 3). Beta can then run the copy to activate an instance of the calling class (step 4).

10.1 Implementation caches

Figure 8: Use of the implementation object

While this procedure is a reasonable investment the first time a host object requires a particular implementation object, it becomes expensive over time. Implementation caches avoid repetitive searches for the same implementation objects by acting as an intermediary between the host object and the class object. In Figure 9, when ClassFoo asks host object Beta to create instance Foo using ImplementationObjectX the host object asks its implementation cache to find a copy of X. In this case, Beta's associated Vault already has a copy, so there is no need to contact host object Alpha. If the cache is unable to find a copy of the implementation object on its vault, it will contact Alpha and make a copy for its host object's associated vault.

Figure 9: The implementation cache

10.2 Implementation tools

When new host objects are added, the legion_init_arch tool will register implementation objects of that architecture for commonly used classes and objects. The tool is run on the new host, so as to create the objects in the proper place. The sample below was run on a Linux host.

$ legion_init_arch
Initializing Legion implementations for "linux"
 
Creating an implementation (ContextObject) for ContextClass
Continue (y=yes, Y=yes to all, n=no, N=no to all, v=verbose, 
	V=verbose all)? Y
Creating an implementation (MetaClassObject) for LegionClass
Creating an implementation (ClassObject) for VanillaMetaClass
Creating an implementation (BindingAgent) for BindingAgentClass
Creating an implementation (BasicFileObject) for BasicFileClass
Creating an implementation (ttyObject) for ttyObjectClass
Creating an implementation (StatTreeObject) for StatTreeClass
$

Implementation objects for a specific binary executable can be created with the legion_create_implementation utility. The resulting implementation object is marked as usable for specific architectures. Usage of the tool is as follows.

legion_create_implementation
<binary path name> <architecture>
{[-c] <class context name> | -l <class LOID>}
[-c] <context path>] [-nc] [-v]
[-a <attribute>] [-debug] [-help]

Currently, possible architectures are

• linux (corresponds to x86 running Red Hat 4.x Linux)
• solaris (corresponds to Sun workstations running Solaris 5.x)
• sgi (corresponds to SGI workstations running IRIX 6.4)
• alpha_linux (corresponds to DEC Alphas running Red Hat 4.x Linux)
• alpha_DEC (corresponds to DEC Alphas running OSF1 v4)
• t90 (corresponds to Cray T90s running Unicos 10.x)
• rs6000 (corresponds to IBM RS/6000s running AIX 4.2).

A new implementation object created with this tool will be associated with the class object named in <class LOID> or <context path>.

The /impls context contains a list of default implementation objects. The list will look something like this:

$ legion_ls -la /impls
.	(context)
..	(context)
AuthenticationObject.linux.1	(implementation)
BasicFileObject.linux.1 	(implementation)
BatchQueueClassObject.linux.1	(implementation)
BindingAgent.linux.1	(implementation)
ClassObject.linux.1	(implementation)
JobProxyObject.linux.1 	(implementation)
MetaClassObject.linux.1	(implementation)
StatTreeObject.linux.1	(implementation)
StatelessProxyClassObject.linux.1	(implementation)
legion_make_backend.linux.1	(implementation)
ttyObject.linux.1	(implementation)
$

In this example, the default context names for all implementation objects are made up of a class name, architecture, and encoded architecture number (i.e., *.1 names represent the first implementation object of that architecture for that class).

The example below creates an implementation object for my_class, using Linux, and has the binary path name of my_obj. The new object will automatically be assigned the context path /impls/my_obj.linux.1.

$ legion_create_implementation Legion/bin/linux/my_obj \
   linux my_class

If you ran the example a second time, the new object would be called /impls/my_obj.linux.2. You can use the -nc flag to specify that no context path be assigned. You can also assign the new object extra attributes with the -a flag.

Use legion_list_implementations to see which implementation objects have been assigned to a particular class.

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