3.1 The Java Parallel Class Library (JPCL)

 

The parallel class library in ParaWeb provides mechanisms for the remote creation and execution of threads, and facilitate communication between these threads. A programmer can create a thread that executes on a remote machine by simply extending the JPCL RemoteThread class and then instantiating the new class. Communication is currently provided in the form of standard message passing send and receive primitives.

The sequence of steps performed in order to execute a parallel program in our current implementation are labeled in Figure 1 and described below.

1. Server sites (Server A, Server B and Server C in Figure 1) start the Java interpreter and initially run a daemon which has been compiled to Java byte-code. Each server daemon then registers with a local scheduling server which is used to keep track of which servers daemons are available, the periods of time during which they are available, authentication and authorization policies, server daemon loads and any other information that is useful for determining which server daemons to utilize and when. At this point these server daemons are ready to accept and execute Java byte-code on behalf of the permitted clients.
2. A Java program creates a thread on a remote machine by simply instantiating a new object that has extended the RemoteThread class. When this object is instantiated on the client machine, the library code implementing the RemoteThread class contacts the scheduling server and requests the address of a server daemon that will execute code on behalf of the client (provided a machine name has not been specified for the RemoteThread).
3. The scheduling server replies with an available server daemon. If a number of remote threads are going to be created, the scheduling server can be asked for a specified number of server daemons. This may also be necessary so that the threads being executed on the remote servers will be able to communicate if the need arises.
4. The instantiated object on the client sends the compiled byte-code (class file) to the remote server daemon, which uses our Java network class loader to load the class from the network directly into memory (rather than copying it to disk and then loading it to memory). The server daemon then calls the run method of the uploaded RemoteThread class which starts the execution of the thread. In the example in Figure 1 the scheduling server has determined that Server A and Server B should be used, while Server C is not used in the execution of this parallel program.
5. The server daemon executes the client's code and sends results back to the client as required by and specified in the application.
6. When the client application completes, it contacts the scheduling server to inform it that it has finished using the server daemons. Note that the server daemons may also be involved in notifying the scheduling server when they have completed the execution of a client's thread. However, the client may wish to further utilize the server to execute other remote threads before its application is completed.

  
Figure 1: Running a parallel program using the Java parallel class library.

One of the major advantages of this approach is that the server daemons execute standard Java byte-code within an unmodified interpreter. Therefore, the server daemon is completely portable and capable of being executed on any computer which executes Java byte-code. The daemon could, for instance, be run inside a Java capable browser.

Naturally, in order to deploy this type of system in a large scale environment, the scheduling server will play a central role. We are developing scheduling servers which will be used to keep track of servers daemons within a local domain as well as methods of communicating with schedulers in other domains. Schedulers will communicate with other schedulers in different domains when sufficient resources are not available locally. These schedulers will also be written using Java so they can be executed portably on a number of platforms.