IceT: Distributed Computing and Java ^{∗}

Paul A. Gray and Vaidy S. Sunderam Emory University, Atlanta GA USA

                                   {gray,vss}@mathcs.emory.edu

Abstract Metacomputing, or distributed processing on networks (local networks, intranets, or the Internet), has

re-emerged as a technology with tremendous promise and potential, owing in part to the emergence of the Java language and programming system. Java both influences and is influenced by the requisite and dynamic aspects of network programming. However, its viability as a programming language for the scientific community is yet to be established. This paper describes IceT, a novel framework for collaborative and highperformance distributed computing which has been built upon a Java substrate. The IceT system exploits the portability and scripting advantages of Java and incorporates well established distributed and concurrent computing techniques into the framework, while retaining the ability to access specialized processing capabilities and precompiled code. The result is a dynamic and efficient distributed computing environment upon which data and processes are highly portable amongst heterogeneous platforms and multiple users.

1 The IceT Objective

There are many contrasts to be found when comparing Internet programming and high-performance distributed computing. Consider, for example, Internet programming as it relates to the World Wide Web. Users are able to anonymously access processes and data at remote locations for remote execution (e.g. a cgi-bin Perl script) or download processes for local execution (e.g. a Java applet). In such settings, issues that need to be addressed include the consequences and implications of executing processes remotely, anonymously, and securely. On the other hand, in high-performance distributed computing, where users’ programs are local and executed on local or organization-wide machines, security is less of an issue and users typically have access privileges (i.e. anonymity is not a factor).

The aim of the IceT project has been to mutually incorporate approaches and techniques found in Internet programming with established and evolving distributed computing paradigms. Necessarily, this includes the ideas of harnessing geographically-remote resources for anonymous utilization, portability of processes and data, in addition to security issues that naturally arise. For a good discussion of some other considerations that need to be made when addressing such a goal, see [2]. The integration of Internet and distributed programming techniques would lead to a natural environment for collaborative computing and an extension to the traditional distributed computing environment. Examples of extended features incorporated into IceT are: dynamic merging and splitting of virtual machines, multi-user awareness, portability of processes and data across multiple virtual machines, and a provisional framework for multi-user programs. This paper describes some of the novel features of IceT and the role played by the Java programming language. Details on what is currently implemented and the future of IceT are given, along with some Java-based examples which serve to further illustrate the novel features of IceT.

Reiterating, the objective in IceT has been to blend current paradigms in distributed computing with new and evolving technologies; including but not limited to the aspects and features found in Java. IceT builds upon traditional message-passing paradigms found in distributed computing, such as PVM[5], and mixes with it wide accessibility and portability of processes as found in both Java and Internet programming paradigms. A typical active IceT environment consists of processes executing in unison across multiple networks, amongst multiple users, and sharing information using IceT’s messagepassing substrate. These processes in IceT are not bound to any particular filesystem or network because processes are able to “soft-install” themselves upon remote systems. In some sense, processes are able to be encapsulated into a portable package which may be uploaded to any processing component within the IceT environment for subsequent execution, governed by the restrictions imposed by the owner of the component.

∗Research supported by Army Research Office grant DAAH04-96-1-0083, U. S. Department of Energy Grant No. DE-FG05-91ER25105, NASA Grant NAG 2-828 and the National Science Foundation Award ASC-9527186.

2 Java and IceT

Loosely speaking, the aspects of Internet programming that have been introduced to distributed computing vis-a-vis IceT relate to uploading and porting of processes and data; and providing combined, provisional access to unowned, remote and heterogeneous resources. The ClassLoader class, SecurityManager class, and the JVM are the major Java components by which these aspects of IceT are realized.

2.1 The Java ClassLoader

¿From the IceT perspective, the Java ClassLoader class is the primary feature of Java which can be used to complement distributed computing. Through the Java ClassLoader, processes represented as Java bytecode can be uploaded, instantiated, and executed on remote hosts where the “owner” of the bytecode has no privileges (e.g. login or file access) and where execution is subject to security restrictions imposed by the owner of the local resource.

In IceT, portability of Java bytecode is achieved by extending the ClassLoader class to load, resolve, and instantiate new instances of classes located on remote hosts. This component of IceT is similar to (albeit functionally the reverse of) a web browser which downloads applets from wide-spread resources across the Internet. A user wishing to upload his/her process to a remote IceT host would do so through an

IceT ClassBootStrapper. The ClassBootStrapper extends the Java ClassLoader and is responsible for

obtaining and resolving bytecode representations of class files to be executed. The ClassBootStrapper also offers configurability; with the ability to impose different levels of security restrictions to users of the local computational resources through extensions to the Java SecurityManager class.

2.2 Security

IceT allows provisional usage of local resources to possibly anonymous users, so naturally issues relating to security arise. Java’s basic language-level security protocols provide a sound foundation for the implementation of security. The SecurityManager class alone provides a quick and easy means for imposing elementary security restrictions. Furthermore, by extending the SecurityManager, SocketImpl, Thread and File classes, the local IceT environment can be configured to accommodate varying levels of restrictions placed upon workload usage, external and local socket connections, process portability and file system access.

2.3 The JVM

As one of the more common aspects of the Java language, the Java Virtual Machine (JVM) provides Java bytecode with a uniform, system-independent view of the underlying architecture. With the guarantee of uniformity of the JVM, bytecode is truly architecturally independent. This aspect of the Java programming language allows platform-independent execution of the Java bytecode regardless of the platform on which the bytecode was generated. This allows any IceT user to execute any IceT process.

3 IceT Illustrated

This section serves to illustrate the suitability of IceT for traditional distributed computational tasks — in the form of a matrix multiplication example — and to illustrate the novel attributes and collaborative features brought about by the enhanced portability of tasks. The examples below assume that an IceT environment has already been established. For details on the adding and merging of resources to the IceT environment, see [6].

3.1 IceT and Traditional Distributed Computing

Consider a distributed program, organized as a master and a collection of slave processes to multiply matrices A and B. One way of distributing this problem is to split A by rows and to pass these sub rows of A and the entire matrix B to the slave process for subsequent multiplication. The following shows how one might program this problem (albeit naively) utilizing IceT and the Java programming language.

The Master Program The first task is to make the master program IceT-aware, this is done by import-ing the IceT-specific commands. In order to interact with IceT components, the program takes the form of an extension to the TaskProtocols class, which defines various IceT functions such as IceT send, IceT recv, etc. In this example, the master and four slaves will be responsible for the distributed multiplication (refer to lines 1-5 below).

      1  import IceT.*;
      2  import java.util.*;
      3  public class MatrixMultiply extends TaskProtocols {
      4    final static int NUM_SLAVES = 4;
      5    final static int NUM_WORKERS = NUM_SLAVES+1;
   ...
     12      try {
   ...
     17        TaskElement myTaskElement = IceT();
     18        /* Prepare to spawn the slaves */
     19        TaskElement[] taskArray = new TaskElement[NUM_SLAVES];
     20        int numSpawned = IceT_spawn("Slave",NUM_SLAVES,taskArray);
   ...
     27        int block = (int) SIZE/NUM_WORKERS;
   ...
     34        /* Pack the entire matrix b */
     35        for (int i = 0; i< SIZE; i++)
     36          bufferB.pack( B[i] );
     37
     38        for (int k =0; k<NUM_SLAVES; k++){
     39          bufferA.reset();

                                                                                                  40          bufferA.pack(SIZE);
                                                                                                  41          bufferA.pack(NUM_WORKERS);
                                                                                                ...
                                                                                                  45          for (int i = 0; i< block; i++) {
                                                                                                  46            int row = k*block;
                                                                                                  47            bufferA.pack( A[row+i] );
                                                                                                  48          }
                                                                                                  49          /* Send off the information to the slave */
                                                                                                  50          IceT_send(bufferA,taskArray[k].myId,888);
                                                                                                  51          IceT_send(bufferB.bufferClone(),taskArray[k].myId,889);
                                                                                                  52        }
                                                                                                ...
                                                                                                  68        // Reap in the results from the slave
                                                                                                  69        for (int k = 0; k<NUM_SLAVES; k++) {
                                                                                                  70          b = IceT_recv(777);
                                                                                                  71          for (int i = 0; i < block; i++) {
                                                                                                  72            int row = k*block;
                                                                                                  73            C[row+i] = b.unpackDouble(SIZE);
                                                                                                  74          }
                                                                                                  75        }

The program initializes its IceT environment and spawns NUM SLAVE copies of the Slave program (lines 17-27). Problem parameters, the slave’s portion of A and the entire matrix B are packed and sent to the respective processes (lines 34-52). The master program calculates the remaining portion of the matrix multiplication (not shown in the listing) while the slaves compute their results. Finally, all the slaves’ computations are collected by the master and the matrix is processed (lines 68-75).

The slave program (not listed) is organized in a similar form; it completes its initialization of the IceT environment like the master program and waits to receive buffers containing the B matrix and those rows of the A matrix that it is assigned. Each slave then computes its respective portion of the matrix multiplication, packs up the results, and returns them to the master program.

This matrix multiplication example is intended to demonstrate the suitability of IceT for traditional parallel/high-performance applications. Additionally, this example shows the consistency with traditional distributed computing programming interfaces of the IceT programming interface, which holds a strong similarity to the existing programming interfaces of PVM and MPI[8]. However, IceT provides some additional features that facilitate the above task. Noteworthy aspects of the matrix multiplication problems which are unique to IceT include:

• Copies of the IceT Master and Slave programs need not be provided to each of the computational resources in the user’s IceT environment. In the absence of finding a process locally, IceT manages the task of locating the process and uploading it to the appropriate resource(s) as necessary.

• In PVM, the user must supply a compilation of the program for each distinct architecture of the resource pool. In IceT, any process can be freely ported and executed within the IceT environment. By using the system-independent language of Java, processes enjoy a wide breadth of architectural freedom.

For performance benchmarks which compare the native IceT/Java matrix multiplication above with variations of equivalent C and PVM implementations, see [7]. Preliminary investigations show that a mixture of distributed computational processes, written in a native language such as C and supported by the scaffolding of IceT, can provide performance very competitive with the equivalent PVM implementation.

3.2 Just-In-Time Process Installation

The focus of the matrix multiplication example was to show that IceT adheres to traditional mechanisms of distributed computing, thereby facilitating its use via well-understood message-passing parallel programs. In addition, IceT possesses additional benefits in process/data portability and in bringing together unrelated or external resources.

As in traditional distributed computing, local processes in IceT can be executed on semi-local resources (as described in the first section). This paradigm is extended in the IceT environment to further allow local processes/data to be uploaded to remote, unowned resources (a colleague’s system, for example), to locate remote processes/data and to download them locally, or any dynamic combination thereof. Processes themselves have the ability to port themselves amongst the resources of the environment provided they adhere to the security imposed thereon. All processes possess the ability to maintain persistent communication with all other processes within the IceT environment, with communication to restricted elements of the environment, governed by the security imposed upon the resources involved. The degrees of portability, local execution of anonymous processes, and permitted communication channels are also governed by the security measures imposed by the owner of the local resource.

“Just-in-time” process installation, also referred to as “soft-installation,” refers to the ability for a process to enter a resource, perform its computation within the restrictions imposed by the environment, and to leave no residual^{1} of the process upon termination or migration from the resource. In IceT, a process has the ability to upload itself to a remote resource, become instantiated as a separate thread of execution^{2}, complete its computational task, and terminate only to be garbage-collected by the JVM. Moreover, this may be accomplished without accessing or storage of bytecode onto the filesystem. This process may also communicate with the various entities enrolled in the conglomerate IceT system without actually opening direct socket connections or being made aware of the ports these entities are listening on. If stringent communication measures are imposed upon the process, the local IceT daemon governs and manages the routing of communication to permitted external entities.

3.3 Examples of Just-In-Time Installations

The usefulness and utility of the just-in-time installation of software has several immediate application areas:

• In the simplest sense, just-in-time installation of software could be used for local and remote data mining. In the situation where the data pool is quite large and the data of interest is relatively small, transference of the data for subsequent parsing or manipulation would take more time than porting of software which would parse the data and return select data of interest or possibly some visualization of the representative data.

• As a facilitating environment for collaboration, the just-in-time installation of software would mean that any person would be able to utilize a vast collection of collaboration software with fellow collaborators. In the event that software necessary for collaboration is lacking from a colleague’s local system, the requisite software could be uploaded to that colleague for subsequent execution and involvement in the collaboration^{3}. IceT provides the substrate upon which collaborative tools would be uploaded and provides the subsequent channels through which these tools would be allowed to communicate.

1Leaving files associated with the process on the local filesystem, for example.

2This thread can be started, stopped, re-prioritized, or even serialized and possibly ported elsewhere or archived for postponed execution — all governed by the local IceT environment and its configuration by the owner of the local resource.

3For a detailed example involving the steps involved the distribution and instantiation of an actual IceT collaborative tool, see[7].

4 Comments on Related Work

There has been considerable progress relating to distributed or collaborative computing using Java [1, 2, 4]. However, the portability and accessibility of processes hasn’t truly been exploited to the level realized in IceT. IceT shares limited similarities with JavaPVM[9], and JPVM[3], and has attributes similar, by design, to PVM. The objective of IceT was to take the traditional features of distributed computing, like those found in PVM, and to extend them to include additional features such as the merging of virtual machines, the dynamic uploading of processes across virtual machines, etc. Both JavaPVM and JPVM address programming aspects and objectives orthogonal to those of IceT, and hence offer features not found in IceT. JavaPVM provides a Java interface to PVM software. JPVM is a PVM-like class library implemented in and for use with Java. Like IceT, JavaPVM and JPVM provide users with an environment suitable for distributed computing. However, IceT’s environment provides the additional functionality of harnessing and merging with remote resources where the user lacks privileges, and directly supports the uploading of processes and data upon aggregated resources.

5 Conclusion

Through IceT, novel ideas from the domain of Internet programming have been incorporated into the realm of distributed computing. As a consequence, users are provided a wider breadth of resources, far-reaching access to processes and data, and an environment well-suited for distributed computing, collaborative computing and multi-user interaction. While IceT is in its relative infancy, the additional attributes brought to distributed computing as illustrated by IceT are quite promising.

References

[1] A. Alexandrov, M. Ibel, K. Schauser and C. Scheiman, SuperWeb: Research issues in Java-based global computing. Concurrency: Practice and Experience, Vol 9(6), pp. 535-553, June 1997.

[2] M. Chen and J. Cowie, Java’s Role in Distributed Collaboration.. Concurrency: Practice and Experience, Vol 9(6), pp. 509-519, June 1997.

[3] A. Ferrari, JPVM. Software package and further information is available at http://www.cs.virginia.edu/∼ajf2/jpvm.html

[4] G. Fox and W. Furmanski, Java for parallel computing and as a general language for scientific and engineering simulation and modeling, Concurrency: Practice and Experience, Vol 9(6), pp. 415-425, June 1997.

[5] G. A. Geist and V. S. Sunderam, The PVM system: Supercomputer level concurrent computation on a heterogeneous network of workstations, Proceedings of the Sixth Distributed Memory Computing Conference, IEEE, April 1991, 258-261.

[6] P. Gray and V. Sunderam, The IceT Framework for Metacomputing, Document available at http://www.mathcs.emory.edu/∼gray/IceT3.ps

[7] P. Gray and V. Sunderam, The IceT Environment for Parallel and Distributed Computing, To appear in Proceedings of ISCOPE97 (Springer Verlag), Marina del Rey CA, Dec. 1997.

[8] M. Snir, S. W. Otto, S. Huss-Lederman, D. W. Walker, and J. Dongarra, MPI, The Complete Reference. MIT Press, November 1995.

[9] D. Thurman, JavaPVM. Software package and further information is available at http://homer.isye.gatech.edu/chmsr/JavaPVM/