When a class object asks a host object to start an instance (Figure 7 step 4), it gives the host object the LOID for an appropriate implementation object. An implementation object typically contains executable object code for a single architecture and operating system platform, as well as any other information that might necessary for instantiating an object on a particular host object (Java code, Perl script, etc.). 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. The host must have a copy of a appropriate implementation object in order to start the instance.
Figure 8 shows how the host object accomplishes this. When class Foo, sitting on host Alpha, sends a call (step 1) to create instance Foo on Beta, it gives Beta the LOID for ImplementationObjectX. Beta uses the LOID to find ImplementationObjectX on Alpha (step 2) and makes a binary copy for its own vault (step 3). Beta can then create instance Foo (step 4).
While this procedure is a reasonable investment if a host object requires a particular implementation object once, it becomes expensive when repeated. An implementation cache circumvents the problem by acting as an intermediary between the host object and the class object. The implementation cache object is responsible for finding and keeping implementation objects on behalf of its host object. We can update the scenario in Figure 8, since Beta can now ask its implementation cache object to locate a copy of ImplementationObjectX, as show in Figure 9, below.
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.
The default context names for all implementation objects consist of a class name, architecture, and encoded architecture number (names ending in *.1 are the first implementation object of that architecture for that class).
You can create Implementation objects for a specific binary executable with legion_create_implementation. The new implementation object is marked as usable whatever architecture you specify. The syntax is:
Please see page 23 in the Reference Manual for a list of possible <architecture> values and explanation of the flags.
The new implementation object will be associated with the class object named in <class LOID> or <class context path>. You must provide a path for the binary executable that will run on your specified architecture. The new object will be assigned the context path /impls/<class_name>.<architecture>.# unless you specify otherwise in the <object context path> parameter or use the -nc flag.
Use legion_list_implementations to see a list of which implementation objects have been assigned to a particular class. The output will be each object's LOID and architecture. The example below lists seven implementation objects for the tty class.