Mobile code toolkit

The central concept of our framework is the proxy server. An application can use the resources of the proxy server to increase the performance and decrease the power consumption by executing selected objects on the proxy server. To enable this approach, we need to identify computationally intense, closely-coupled groups of objects and encapsulate them in a mobile agent. This agent may execute locally or be shipped to the access network, depending on the wireless link conditions and the available resources at both the portable device and the proxy server.

3.1 Toolkit design

Our goal is to extend the Java Virtual Machine with a toolkit that facilitates the mobility of objects between portable device and proxy server in a dynamic manner, transparent to the application designers and users. This toolkit is designed to work on PDAs with a limited amount of memory. Other existing ORBs and object mobility toolkits do not support these platforms or they have too big a memory footprint.

The toolkit has a set of APIs, which provides the required functionality for moving objects dynamically. One instance of the toolkit executes on both the portable device and the proxy. It contains the following major modules:

- Monitor: monitors and delivers the state of the portable device and the proxy server as events to the Object Server. Changes in the bandwidth or changes in the power status are examples of the events that this unit exports.

- Code Storage: storage of the validated classes files (bytecode) at the portable device.

- Object References and Profiling: representation of the application's objects along with the profiling information about these objects.

- Object Server: core of the toolkit. It runs a thread that listens continuously to all the commands from a remote object server. Commands can be related to moving objects or related to the remote invocation of a method on a remote object.

- Remote Method Invocation Protocol: marshal and un-marshal a method's parameters.

- Dynamic Decision: analyzes the profiling information of application's objects. It resides only at the proxy server.

- Communication Control Layer: simulates wireless links in terms of low bandwidth. We introduce a controllable amount of delay between data packets, which allows us to control the throughput dynamically at run time for testing purposes.

In our toolkit, every movable application object is associated with a proxy object that has the same interface. Other objects will not reference application objects directly, but they reference them through their proxies. Assume a simple application with two objects, A and B. Initially, four objects reside at the portable device: A, B, A's proxy, and B's proxy. B references A, so in our toolkit B will contain a reference to the proxy of A. Moving B from the portable device to the proxy server will not require moving A to the proxy server as well. However, at the proxy server, a proxy of A must be created to forward the calls to A at the portable device. Also, a new proxy of B will be instantiated at the proxy server to allow local objects there to reference B.

Should the toolkit migrate A to the proxy server, changing the reference to A in B is not required since B references only the proxy of A (which will remain behind at the portable device). Any calls from B to A will be forwarded remotely through the proxy at the portable device.

3.2 Distributed garbage collection

Every proxy object created in the toolkit is assigned a local and a remote reference counter. These counters are updated whenever a proxy object is referenced locally or remotely and are used to determine when the garbage collector can claim the proxy and its associated object. Whenever a proxy object is not being referenced remotely and locally, it will be finalized and garbage collected. If the associated object of this proxy is local, then the associated object will be finalized and claimed again by the garbage collector as well. If the associated object is remote, then the proxy object will inform the remote object server to decrement the remote reference counter for the associated object at the remote site, which in turn garbage collects the object if there are no further references locally or remotely to the associated object.

3.3 Toolkit performance

To obtain a first impression of our toolkit performance, we performed a few simple tests, comparing various aspects with Voyager [OBJ 99], a popular mobile code toolkit. The following table compares the measured overhead of the toolkit against Voyager. The measurements were taken under Windows NT on a Pentium II 350 MHz PC.

Table 1. Overhead comparison

Voyager

Our toolkit

Footprint

2620 KB

204 KB

Moving object

142 ms

80 ms

Calling a method

23 ms

110ms

Based on these results, we are confident that our toolkit can be used for small portable devices such as Palms and PDAs. The memory requirement of our toolkit is small compared to Voyager (which supports many additional features such as CORBA compliance), allowing it to be embedded in these small devices. The cost of migrating the objects compared to Voyager is lower as well; however, we still need to improve the remote method invocation protocol.

3.4 Automatic agent identification

In the final version of the toolkit, we also expect to provide support for the automatic identification of suitable mobile agents. In essence, suitable mobile agents are sets of application objects that consume lots of CPU time and communicate heavily. Currently, we are profiling applications with a Java profiler, derive information about objects, their CPU consumption, and their interaction patterns, and use an external clustering algorithm to determine a suitable set of application objects to group as agent. This external definition of an agent is then used by the mobile code toolkit. For our MP3 player, Table 2 lists the instances (objects) that exist during the decoding of MP3 frames and some information about their CPU time consumption. This profiling information was measured on a 350 MHz Pentium II PC.

Table 2. MP3 player profiling information

Object Name

Data Size (bytes)

#of Instances

Code Size (bytes)

Calls/Frame

Avg. CPU Time/Instance

Table43

28

1

107344

620

0.00794

Bit_Reserve

16666

1

1430

3355

0.50058

SBI

223

6

2905

97

0.01926

gr_info_s

376

4

5195

7184

0.06222

temporaire2

376

2

1409

1687

0.00445

Temporaire

593

2

1819

52

0.22175

Header

765

1

9245

11

0.00267

III_side_info_t

959

1

2022

35

0.16715

Ibitstream

1972

1

5301

449

0.29177

huffcodetab

2526

35

45493

693

0.11331

SynthesisFilter

4414

2

18724

4824

0.44725

LayerIII_Decoder

25114

1

47146

160

1.07052

The profiler also collects information about the number of method invocations and the number and size of parameters exchanged. Most objects communicate only relatively infrequently, but some communicate frequently, with lots of data being passed. Unfortunately, the heavily communicating objects are not necessarily the most CPU-intensive objects. The clustering algorithm therefore starts with the computationally heavy objects and adds additional objects to the group to reduce "coupling". Some objects, such as those implementing the GUI component or the one interacting with the local sound card, cannot be migrated to the proxy server. In our application environment, "coupling" measures the amount of inter-object communications between the mobile agent and the remaining application objects. Should the toolkit decide to migrate the agent to the proxy server, such inter-object communication will result in remote method invocations, and we aim to minimize the traffic over the slow wireless link. In the future, we hope to integrate profiling into our toolkit to allow us to determine appropriate agent candidates dynamically at runtime. This also enables us to track changes in the application behavior and to react to them appropriately.

0 0

Post a comment