Approaches to Capturing Java Threads State

Transcription

1 Approaches to Capturing Java Threads State Abstract This paper describes a range of approaches to capturing the state of Java threads. The capture and restoration of Java threads state have two main purposes: to make Java applications mobile and to make them persistent. We compare different approaches, give a preliminary evaluation and describe our ongoing work in this area. 1 Introduction The Java Virtual Machine (JVM) [Lindholm96] provides the abstraction of a homogeneous environment, and the Java Development Kit (JDK) [Sun99] provides many tools which help developing applications, such as object serialization that captures the state of an object and dynamic class loading that captures a Java code. However, Java does not provide any service for capturing execution (thread) state. A mechanism for the capture/restoration of Java threads state might be used in order to implement mobile applications or persistent applications. We first give a brief overview of the structure of the state of a Java thread, and then describe several approaches to providing a service for capturing/restoring a thread state: on top of the JVM, by extending the JVM and its Java interpreter, or by extending the JVM without modifying the interpreter. 2 Description of the state of a Java thread The state of a Java thread, which is internal to the JVM (not visible by Java applications), consists of: the Java stack, organized in blocks called frames and associated with the Java methods currently being executed by the thread. A frame contains a table of the local variables of the associated method, an operand stack containing the values of the partial results of the method, and some registers like the pc (program counter) which points to the Java byte code instruction currently being interpreted, the code, i.e. the set of Java classes that include a Java method currently being executed by the thread; these classes are referenced by the frames of the Java stack, and the data, including the values of the local variables and the partial results of the Java methods currently being executed by the thread. 3 First approach: On top of the JVM 3.1 Objectives and Design principles The objective of this technique is to extract the state of a thread from the code of the underlying application. This is done by pre-processing the source code of the application in order to insert checkpoints and 1

2 Java statements which back up the thread state in a backup Java object. The inserted statements are used to build a backup objet that evolves with the execution and contains information relative to the methods currently being executed by the thread, the last checkpoint in each method, and the state of the local variables of each method. At snapshot time, the application just uses the backup object. Using the backup object, the thread state is restored to the value saved at snapshot time. This restoration operation requires a partial re-execution of the application in order to rebuild the Java stack frames and to update the methods local variables. Finally, the restored execution is resumed. 3.2 Discussion This technique is used in the Wasp mobile agent platform [Fünfrocken98]. The main motivation of this approach is that it is portable on all JVMs. We have installed and evaluated the Wasp mobile agent platform. Here are the results of some preliminary measurements performed on the JDK 1.1.3, on Sparc hardware running Solaris 2.5 [Bouchenak99a]. We first noticed that the average cost of a thread state capture/restoration operation is 25 ms which is quite significant. As the capture of the state is done during the execution of the application, the capture operation, at snapshot time, is virtually free. But the restoration of a state requires a partial re-execution of the Java application and accounts for the major part of the cost. We also noticed that the use of this capture mechanism induces a factor of the order of 130 on application execution time; this is due to the execution of the statements inserted into the application source code. 4 Second approach : Extending the JVM and its Java interpreter 4.1 Objectives and Design principles The objective of this technique is to extract the state of a Java thread from the JVM by extending it. The principle of this extraction is to copy the state in a Java object (called ThreadState in this paper). The capture of a thread state consists in building a ThreadState object that reflects the current state of the thread. This is done by parsing the Java stack of the thread and saving the information relative to the thread state (section 2) in the ThreadState object. The Java stack is represented in the JVM by a native C structure. To make the capture mechanism portable on heterogeneous machines, each value on the stack is translated from the native format to a portable (Java) format. This translation requires the knowledge of the types of the values. But the local variable tables and operand stacks on the Java stack do not provide any information about the types of the values they contain: a four bytes word might represent a Java reference as well as an int value or a float value. So the problem is to determine the types of the values on the Java stack. The byte code instructions are typed and each instruction is applied to a particular type: the istore instruction stores an int value in the current local variable table, the aload instruction loads a Java reference on the current operand stack, etc. When interpreting a byte code instruction, it is possible to know the type of a value stored in 2

3 a local variable table or an operand stack. So the Java interpreter is extended in order to build a type stack parallel to the Java stack, which evolves with thread execution and contains the types of the values on the Java stack. Therefore, when capturing a thread state, the types of the values are given by the type stack and these values can be translated from a native (non typed) format to a portable format. The restoration of a Java thread state starts first with the creation of a new thread and then the initialization of its state with the information contained in a ThreadState object, relative to the code, the data and the Java stack. Finally, the execution of the new thread starts at the point at which the previous execution was interrupted. 4.2 Discussion Our implementation We have implemented a mechanism that follows this approach and performs the capture/restoration of Java threads state. The objective of our project was to add a new service to the JDK, provided through a Java class. On the one hand, this service can be combined with other Java services like object serialization or dynamic class loading in order to implement higher level services like thread migration or thread persistence; on the other hand, higher level services can be adapted to applications needs by specializing object serialization and class loading. Our mechanism was implemented within the JDK [Sun99]. The interface of the provided service is briefly described in Figure 1. The ThreadState class specifies a Java object that describes the state of a Java thread. The ThreadStateManagement class provides two methods: capture, which captures the state of the current Java thread and stores it in a ThreadState object; and restore, which creates a new thread, initializes it with a given thread state and starts it. public final class ThreadStateManagement { /* Captures the state of the current Java thread and returns it as a ThreadState object. */ public static ThreadState capture(); /* Creates a new Java thread, initializes it with the threadst state and starts its execution. */ public static Thread restore(threadstate threadst); } Figure 1: Interface of our Java thread state capture/restoration service We have done some preliminary experiments with our mechanism, like thread migration, remote thread cloning and thread persistence. A description of these experiments can be found in [Bouchenak99a] Sumatra/D Agents The JVM extension technique has also been used to implement the Sumatra [Ranganathan97] and the D Agents [Gray99] mobile agent platforms, which provide strong migration for their agents. For the Ara mobile agent platform [Peine97], which supports agents written in Tcl and C/C++, an integration of Java agents, following a similar approach, is underway. From a functional point of view, the difference between the Sumatra/D Agents platforms and our 3

4 implementation is that they provide a complete distributed system with a mobility service for their agents while we provide a new service for the JDK, a service that can be combined with other Java services and used to implement either mobility or persistence. Note that our service provides the internal state of a thread and does not manage its external state, i.e. resources like files or communication channels. So when implementing thread migration or thread persistence on top of our service, such resources should be managed according to applications needs. We also notice that the JVM extension approach requires modified JVM, which is detrimental to the portability on other Java platforms. We performed some preliminary measurements of the cost of our mechanism [Bouchenak99a]. We now compare our results with those of the Wasp platform. We first noticed that with our mechanism, the average cost of a thread state capture/restoration operation is 7 ms, which compares favorably with the 25 ms induced by Wasp s mechanism. This performance difference is due to the fact that our mechanism was integrated into the JVM while Wasp s mechanism was implemented on top of the virtual machine. We also noticed that due to the extension of the Java interpreter, the use of our capture mechanism by an application induces a factor of 10 on application execution time. This overhead is an order of magnitude less than that induced by Wasp s mechanism, but it is still large. The approach described in section 5 aims at eliminating this overhead. 5 Third approach: Extending the JVM without modifying its Java interpreter 5.1 Objectives and Design principles The above discussion has identified two sources of overhead for a Java thread capture and restoration service: the cost of the mechanism itself, which can be reduced by extending the JVM, the overhead induced on the execution of the application, which can be eliminated if the Java interpreter is not modified. The idea of the third approach is to extend the JVM without modifying the Java interpreter, thus attempting to reduce both sources of additional costs. With this approach, the capture and the restoration of the state of a thread are performed in the same way as the technique described in section 4. And by leaving the interpreter unmodified, no execution overhead is incurred. However, the problem to be solved is to recognize the types of the values on the thread s Java stack. Like in the second approach (section 4), a type stack parallel to the Java stack of a thread and containing the types of the values on the Java stack must be built. But unlike the second approach, the construction of the type stack associated with a Java stack is not performed during the execution of the application but at state capture time, which does not require the interpreter to be modified. Since the byte code instructions are typed, the principle of the solution is to guess which byte code instructions were used to push the values onto the Java stack (in the local variable tables and operand stacks). For each frame on the Java stack, the pc value points to the last instruction executed by the thread in the 4

5 corresponding method. Since the code of this method is known, parsing the instructions until the last instruction executed by the thread in the method allows the types of the local values to be recognized. While parsing the code from the first instruction of the method to the instruction pointed by the pc, three instruction kinds may be found: An instruction that recognizes a type. Such an instruction may a) push a value onto the operand stack: the corresponding type is pushed onto the type stack; or b) pop a value from the operand stack: the corresponding type is popped from the type stack; or c) read/write a value from/to a local variable: the corresponding type is assigned to the corresponding variable in the type stack. Then the next instruction is processed. A branch instruction. With such an instruction, parsing the code might not be sequential. The following instruction might be the next instruction or an instruction pointed by a branch address, depending on the address of the last instruction executed by the thread, the branch address and the address of the current branch instruction [Bouchenak99b]. There are many kinds of branch instructions: unconditional branch like the goto instruction, conditional branch with two choices like if instructions and conditional branch with many choices (many branch addresses) like the switch instruction. Other instruction. In this case, nothing is done and the next instruction is processed. 5.2 Discussion We do not know of any implementation of the above technique to capturing/restoring Java threads state. Our own implementation is in progress; it provides the interface described in Figure 1. We are currently in the process of validating a first version. Here is our prediction for the performance of this mechanism. First, this technique should not induce any overhead on applications performance because the capture of a thread state is performed only at capture time: nothing is done during the application s execution like in the first approach (statements inserted in the application code) or the second approach (Java interpreter extended). Then, with this mechanism, the cost of a capture/restoration operation should be, on the one hand, lower than the cost of the same operation with the first technique because the first technique is implemented on top of the JVM while the proposed one is implemented within the JVM. On the other hand, the cost of a capture/restoration operation should be higher than its equivalent with the second technique because the proposed technique performs an additional processing during the capture: parsing the code to recognize the types of the values. 6 Summary and future directions We have reported on several approaches to capturing/restoring Java threads state. Two observations concerning the design of a Java thread state capture/restoration service are important: The JVM extension approach reduces the additional costs induced by a capture/restoration service. With a JVM extension approach, either the Java interpreter is extended and this induces an overhead on application performance; or the Java interpreter is not modified and there is no overhead on application 5

6 performance but an additional cost on the service itself. We have experimented the implementation of the first technique proposed by the Wasp project and given a preliminary evaluation of this technique. We have implemented, evaluated and experimented the second technique. And we propose an implementation of the third technique that we are currently validating on the Java 2 SDK (formerly JDK 1.2). We have compared our implementations to their peers in the Java mobile agents area; and an experimentation and performance comparison with the D Agents platform is planned. We are also investigating the related work in order to compare our work with those achieved in the Java persistence area. Bibliography [Bouchenak99a] S. Bouchenak. Pickling threads state in the Java system. Third European Research Seminar on Advances in Distributed Systems (ERSADS 99), Madeira Island, Portugal, April [Bouchenak99b] S. Bouchenak. Java threads : thread state Capture/Restoration. [Fünfrocken98] S. Fünfrocken. Transparent Migration of Java-based Mobile Agents (Capturing and Reestablishing the State of Java Programs). Proceedings of Second International Workshop Mobile Agents 98 (MA 98), Stuttgart, Allemagne, September [Gray99] R. Gray. D Agents. Dartmouth College. [Lindholm96] T. Lindholm et F. Yellin. Java Virtual Machine Specification. Addison Wesley, [Peine97] H. Peine and T. Stolpmann. The Architecture of the Ara Platform for Mobile Agents. 1 st International Workshop on Mobile Agents (MA 97), Berlin, Germany, April [Ranganathan97] M. Ranganathan, A. Acharya, S. D. Sharma et J. Saltz. Network-aware Mobile Programs. Proceedings of the USENIX Annual Technical Conference, Anaheim, California, [Sun99] Sun Microsystems. Overview Of Java Platform Product Family, Sun Microsystems. 6