Results of Measurements

According to the requirement R11 the size of executable code which moves over the network should be lower when using adaptation, than when using static customization. An objective of this section is to derive an equation from the measured code sizes. The equation should help to decide whether adaptation induces a gain of bandwidth.

The customized application is based on adaptors identical to those of the prototype version using dynamic adaptation. Thus, it is sufficient for the comparison of the size of executable code to compare the size of used implementation classes, eventual dynamic libraries and profiles neglecting the size of the core. The size of the core can be neglected because an identical core is also used for the customized version.

 

size of size of

[-1.5ex]implementation [-1.5ex]size of serialized environment implementation dynamic library

[-1.5ex]group [-1.5ex]profiles [byte] class [byte] [byte]

AIX, PPC 1724

IMemory 1046 Linux, X86 1788

WindowsNT, X86 978 18209

AIX, PPC 2415

IHarddisk 1052 Linux, X86 2599

WindowsNT, X86 1090 17965

Unix 1275

[-1.5ex]IDefaultWebClient [-1.5ex]891 WindowsNT, X86 1369 19785

Unix, Netscape 2607

Unix, Lynx 2335

[-1.5ex]IConfiguration [-1.5ex]1408 WindowsNT, Netscape 2781 20187

WindowsNT, IExplorer 1362 19788

The customized version holds references to all implementation classes over the whole lifetime of the application. When the mobile code moves to a new host, the serialized objects are also moved along. The approximation for the code size of the customized version (s. section ) is the sum of the sizes of all implementation class files of the implementation groups IMemory, IHarddisk,IDefaultWebClient,IConfiguration (s. table ):

with

The prototype version only holds references to implementation classes which are suitable for the current environment, i.e. one implementation class out of each implementation group. If the mobile code moves to a new host, the objects are dropped. For loading a required implementation class, the context awareness loads the instantiated and serialized profiles of all implementation classes of an implementation group.

The approximation for the code size of the prototype version is the sum of all serialized profiles and the arithmetic mean of the implementation classes. The arithmetic mean of the implementation classes represents the implementation class that is suitable for the current environment and actually loaded. Due to differing sizes of implementation classes for different environments, the arithmetic mean is taken in order to get an environment independent unit of measurement.

The approximations of the size of executable code show that the prototype version (11520 [byte]) is smaller than the customized version (22323 [byte]). From this approximations a general equation for R11 can be derived:

If the number of profiles and implementation classes increases and the average size of the implementation class is assumed to be constant, the size of profiles and the sum of implementation classes becomes much bigger than the average size of the implementation class. Thus the average size of the implementation class can be neglected and the equation can be established for each implementation class and its profile:

As long as the size of the profile is smaller than the implementation class requirement R11 is fulfilled.

This equation can be taken to decide whether bandwidth can be saved when using adaptation. This equation is a very rough rule and can only be taken for a first approximation. Especially the sizes of the executable code may strongly depend on the environment. As shown in table some implementation classes are rather small, but need to load big dynamic libraries, containing native code. This aspect is not taken into account for the derivation of the equation, because they are only specific for a few environments in this scenario.

A moderate increase of runtime as cost for the gain of bandwidth is the target of R12 and R13. R12 postulates low reconfiguration time and R13 low time for the call of adaptable methods. In the proposed methodology (s. section ) the method call is used as the event for adaptation. Because of this integration of method calls and adaptation the requirements R12 and R13 are jointly evaluated: low runtime overhead of adaptable methods . The overhead consists of two parts: the execution of context awareness and the loading of the implementation classes (s. figure ). The adaptation is done, when the reference to a class is accessed in a new environment for the first time. Thus there is only an increased latency for the first method.

 

Figure: Runtime latency due to dynamic adaptation  

In the prototype and the customized version the methods of the adaptable classes are called as shown in figure . The gray colored method calls must carry out adaptation before they can execute their tasks.

 

Figure: Sequence of method calls  

The latency due to adaptation in the first method call of the object and the unchanged runtime for succeeding methods is proved by the measurements (s. table ).

 

[-1.5ex]reference [-1.5ex]method dynamic adaptation static customizing

m_memory getPhysicalMemorySize() 346 9

getFreeDiskSpace() 211 83

[-1.5ex]m_harddisk getTotalDiskSpace() 48 45

setDiskSpace() 467 20

[-1.5ex]m_configuration setMemoryCache() 13 13

The method getFreeDiskSpace() of the reference m_harddisk has a higher runtime for the prototype version than for the customized version. The method getTotalDiskSpace() of the reference m_harddisk, which is invoked in the program flow after getFreeDiskSpace(), has almost the same runtime as the method of the customized version.

The values in table are measured on a single-user host with a local repository. Each value in the table is the arithmetic mean of a set of 100 measured runtime values.

 

dyn. adaptation - ratio

[-1.5ex]reference [-1.5ex]method stat. custom. per method

m_memory getPhysicalMemorySize() 337 0.97

getFreeDiskSpace() 128 0.61

[-1.5ex]m_harddisk getTotalDiskSpace() 3 0.06

setDiskSpace() 447 0.96

[-1.5ex]m_configuration setMemoryCache()

The latency because of adaptation is partially up to $97\%$ (getPhysicalMemorySize()) of the total runtime of the method. This is a high ratio and contradicts requirements R12-R13. The reason for the high ratio is the short runtime of the method and the delay caused by the adaptation process at the first method call. If the latency of adaptation is considered over all methods of a reference the ratio of latency per method is more acceptable. If the latency for adaptation is assumed to be constant, adaptation becomes cheaper in terms of runtime. The assumption of a constant runtime of adaptation relies on the fact that the biggest portion of runtime is spent for loading the profiles and executing the context awareness. If the complexity of profiles remains at a constant level, the runtime for context awareness and thus for adaptation can be assumed to be constant.