When a user asks a class object to create an instance on another host, the class must do the following: determine what kind of architecture the new host has, contacts the correct vault object to request persistent storage space and to assign the new object a LOID and an OPA, and contact the correct host object and ask it to start the new object on the host using a particular implementation object. Figure 5 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. 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 6, step 1). Host object Beta must now find a copy of the appropriate implementation object, which is stored on its associated vault (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).
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 7, 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.
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.
A new implementation object created with this tool will be associated with the class object named in <class LOID> or <context path>. The example below creates an implementation object for my_class, using Linux, and has the binary path name of my_obj.
$ legion_create_implementation ~/Legion/bin/linux/ my_obj linux -c my_class $