Seamless Thread and Execution Context Migration
within a Java Virtual Machine Environment
Student:
Andrew Dorman
s2009700@student.rmit.edu.au
Supervisor:
Dr. Caspar Ryan
caspar@cs.rmit.edu.au
ABSTRACT
This paper describes a mechanism for preserving the execu-tion state of a Java applicaexecu-tion during the migraexecu-tion process between two hosts. By using the Java Platform Debugging Architecture (JPDA), this project aims to seamlessly mi-grate both the object and its point of execution to a desti-nation host, without session interruption.
Keywords
Java, code mobility, state migration, thread migration, dis-tributed Java, JPDA.
1.
INTRODUCTION
With the introduction of cheap and powerful computers, there has been a shift away from centralised mainframes to Networks of Workstations (NOW) [2]. These workstations are often under utilised, performing light tasks and leaving the processor idle for substantial periods [13]. Mobile ob-jects provide a means to better utilise resources by moving applications to lightly loaded or idle hosts.
Java’s ability to operate across heterogeneous environments has lead to it becoming a popular choice for mobile applica-tions. While it provides support for object mobility through serialization, dynamic class loading and Remote Method In-vocation (RMI), Java does not provide a framework for the migration of execution state. Current implementations of the Java Virtual Machine (JVM) do not allow the serializa-tion of threads [5], leaving programmers to implement their own software solutions for state preservation.
This project intends to investigate strong migration1, using the Java Platform Debugging Architecture (JPDA) to cap-ture the execution state of a thread, migrate it to a remote host, and resume processing at the point it left off. This 1Strong Migration transfers the mobile object and its exe-cution state See ‘Background’ for a full description.
system will allow for mobile objects to keep session state during host transfers.
This paper is organised as follows. Section Two presents background material concerning mobile objects, while Sec-tion Three provides the raSec-tionale behind our project. Details of other systems implementing strong migration in Java are outlined in Section Four. Sections Five and Six explain our project goals and methodology respectively.
2.
BACKGROUND
With the increasing size and complexity of networks there has been much research into mobile objects. Their ability to suspend execution, migrate to a new host and resume processing provides a flexible approach to distributed com-puting.
Object mobility falls into two categories: that ofWeak Mo-bility and Strong Mobility [6]. Weak mobility transfers the object and its data to the target host, while strong mobility additionally transfers the execution state. This project is only concerned with strong mobility.
Objects migrated using weak mobility must restart their ex-ecution afresh on the destination host, as there is no way to determine their point of execution before they were trans-ferred. This approach may be suitable for maintaining fault tolerant systems, where it is acceptable for processes to restart and continue, but is not desirable for session depen-dant applications where execution state is important. In order to implement strong mobility we must have access to the object to be migrated, the object’s state, the method call stack and the program counter [7]. Java is an interpreted language, wih programs executed in the Java Virtual Ma-chine (JVM). The JVM emulates a host environment, acting as a layer of abstraction between the application and the platform. Stack frames and program counters for threads currently running are maintained in the JVM, which runs as one process on the host operating system. For this rea-son, it is not possible to obtain state information of a Java thread by acessing operating system processes, for this data is within the JVM.
Java implements many key features to support code mobil-ity in its Application Programming Interface, such as Re-mote Method Invocation for the transportation of objects between hosts, and serialization to save the current object
state. While serialization will persist object data it does not capture the point of execution, hence threads are not able to be serialized [11]. Java disallows dynamic inspection of the stack, preventing retrieval of the program counter, and does not currently support a mechanism for storing the execution point of a program.
There exists implementations of techniques for strong migra-tion in Java, which have sought to overcome the platform’s short comings. Some of these include:
• Using a pre-processor to insert variables tocheckpoint
program execution. These variables are then evaluated on the target host to reconstruct execution [5]. • Throwing Java Exceptions at migration time to
cap-ture execution state. The Exception Object is then transferred to the target host along with the object to reconstruct execution context [12][7].
• Modifying the Java Virtual Machine to support the migration of execution context [3][4][1].
While these mechanism achieve strong migration, they suffer greatly in terms of performance and or portability.
The Java Platform Debugging Architecture (JPDA) [9] is a‘request-event’2 based framework for the development of debugging applications. Debuggers are able to‘hook into’
programs running in the JPDA by requesting notification of events fired by the framework, eg. variable modification, exception, stepping, method entry and method exit events.
Handlermethods are activated in response to these events, allowing developers to implement the debugger’s function-ality and further query the running program.
Once an event has been fired and caught by a handler, the JPDA permits the debugger to access information not nor-mally available to Java applications. In particular the abil-ity to obtain stack frames, variable values and the point at which execution was suspended are of particular interest to this project.
Figure 1 shows how the JPDA is logically divided into a
Back End and a Front End, connected via a Communica-tion Channel. These layers are implemented using theJava Virtual Machine Debug Interface (JVMDI), theJava Debug Interface (JDI)and theJava Debug Wire Protocol (JDWP)
respectively. The program being debugged is termed a De-buggee, while the application performing the debugging is theDebugger.
The JVMDI defines the methods and functionality a Virtual Machine provides in JPDA. It contains a native code im-plementation of these methods, which developers with spe-cialised debugging needs may choose to call directly from other native code applications.
The JDWP specifies the format for communications between the debuggee (back end) and the debugger (front end). It 2For more information on Java’s event framework see [8].
Back End
JVM
Front End
User Interface
Debugger
Debuggee
JDI
JDWP
JVMDI
Com.
Channel
Figure 1: JPDA Overview [9]
does not specify the exchange mechanism, only the format of the data.
The JDI contains high level interfaces, written in Java, that provide developers with convenient methods for debugger creation. The JDI utilises the lower layers of JPDA (JDWP and JVMDI), in order to obtain the required data and event notification.
The division of the JPDA makes remote debugging of ap-plications possible, as the front and back ends may be on separate hosts. In addition the debugger and debuggee may be running different Virtual Machines and/or on different platforms.
Developers may choose to implement their product at any level of the JPDA. Debuggers not written in Java may con-nect directly to the JDWP for remote access the JVM, or the JVMDI for only local access. While it is recommended that applications use the JDI, developing at the JVMDI level may provide better support for more specific debugging re-quirements.
It is using this framework that we intend to capture the execution state of a thread, migrate it to the destination host, and have it resume at the point it left off.
3.
RATIONALE
The Java programming language has been designed with portability in mind. Source code is compiled into an in-termediate form calledbyte code, unlike C and C++ which are transformed into native machine code. The byte code is then interpreted into an executable form by aJava Vir-tual Machine (JVM), in which all Java programs are run. This allows developers to write and compile their applica-tions once, and have them execute on any platform imple-menting a JVM. This ability to operate across heterogeneous environments, makes Java highly suitable for implementing distributed or mobile application.
The JVM is disigned to act as a layer of abstraction between the application and the host operating system, defining a standard set of operations and functions available to a Java application. Modifying the JVM to incorperate addition-aly functionality compromises the portability of the Java framework. Systems that require anon-standard JVM may only be deployed on hosts implemeting the vendor specific interpreter, removing an applications ability to operate in a
hetrogenious environment.
Computing in today’s society is no longer strictly confined to the office. Employees who are travelling to meet with customers or performing field work often switch between desktop, laptop and personal digital assistant throughout the day. Mobile objects implementing strong migration, al-low applications to move with workers across devices with-out losing session state, thus seamlessly transferring between hosts.
The implications for strong migration are not restricted to moving applications between devices. The ability to cap-ture the execution state of threads allows for application check-pointing. Each checkpoint may be kept in non volatile storage and restored in the event of an application or host failure.
We intend to address the lack of strong migration support within the language by using the Java Platform Debugging Architecture (JPDA), to preserve execution state.
4.
LITERATURE REVIEW
This section details implementations of existing techniques for strong migration in Java, and how this project intends to address their short comings.
Exception Handling
With the aid of a pre-processor and code insertion, Sekiguchi’s JavaGo [12] utilises Java’s exception handling capabilities to preserve execution state during migration. Methods ca-pable of initiating object transfer are demarcated with the primitive migratory, and have try - catch blocks capable of responding toNotifyMigration exceptions inserted. Ad-ditionally, a variable acting as an artificial program counter is included and continuously updated during the program’s session. For each method within the application, the pre-processor creates astate object, which is used to store local variable values at migration time.
Upon the decision to migrate, aNotifyMigration exception is thrown and caught within the current method, allowing the saving of local variables to thestate object. The excep-tion is propagated to the calling method, repeating the state saving process for each method on the stack and chaining subsequent state objects together.
To facilitate state restoration on the destination host, the pre-processor transforms method signatures to accept a state object as an extra parameter, and is used to initialise lo-cal variables upon reconstruction. Methods are also trans-formed to includeswitch-caseblocks encompassing individ-ual statements, which upon evaluation of the execution point variable, can resume the program at the correct point. Con-trol structures such asfor and while require a more com-plex code insertion technique involving codeunfolding and duplication. This results in an increased method size of
O(n2)[12, p. 219], wherenis depth of nested loops. Sekiguchi’s technique of state preservation incurs a heavy performance reduction on the application, due to the pre-processor’s code insertion. The approach described in this project will remove the requirement for large amounts of
tracking and restoration code, instead utilising the JPDA to extract the required information to restore execution state on the destination host.
Variable Insertion
The Automatic Distribution of Java Applications (AdJava) [5] system, developed at the University of Adelaide, relies upon code insertion to maintain the execution state. By pre-processing the source code of a thread, alevel variable is inserted and incremented after each statement in therun
method, acting as an artificial program counter. Upon mi-gration this variable is serialized with the object data, and transferred to the destination host. To resume execution, thelevelvariable is evaluated through a series ofswitch-case
statements, jumping to the current point of execution. The variable insertion technique used by AdJava causes a substantial increase in code size, an approximate ratio of
1:3[5, p. 74]. This increase is responsible for higher memory consumption as well as longer transfer and execution time. A further limitation is that the artificial program counter is only inserted in the run method of the thread. Should the thread be suspended whilst in a called method, all com-putations completed since leaving run will be lost. This poses performance issues should migration be frequent, or if method calls are deeply nested, as more time is required to repeat calculations hence slowing program progression. This project intends to capture the state of a thread us-ing the JPDA, eliminatus-ing the need for code insertion. By reducing the number of statements to be executed, a de-crease in application running time will be achieved. Fur-thermore, this project aims to increase the granularity of state preservation, removing the need to repeat previously executed commands upon reconstruction.
JVM Modification
Systems based on exception handling and code insertion have all worked within the current confines of the JVM to transfer the execution state. However, researchers at IN-RIA’s SIRAC Project [3] and the University of Meryland’s Sumatra Project [1] have both modified the JVM to allow replication and access to internal data structures, making thread state capture and transfer possible. INRIA’s imple-mentation provides a more elegant and complete set of Java interfaces for development, and therefore shall be discussed in this paper.
To support the changes made to the JVM, SIRAC provides two new classes,MobileThread(which extendsThread) and
ExecutionEnvironment. MobileThread callsextractExecEnv
at migration time, storing the current execution state in a variable of type ExecutionEnvironment. transferExecEnv
is called to perform the migration to the destination host, whereintegrateExecEnvcreates a new thread initialised with the ExecutionEnvironment.
For security reasons, all methods and data of ExecutionEn-vironment are private (with the exception of the array of class names, which is required by the class loader), and may only be accessed by MobileThread’sintegrateExecEnv. This
avoids the possibility of illegal access to objects on the stack, whilst still providing for the needs of migration.
The advantages associated with JVM modification are pri-marily performance based, due to the lack of code inser-tion and complex restorainser-tion procedures seen in other im-plementations. Benchmarking performed by SIRAC shows that JVM modification can perform up to 13 times faster than Funfrocken’s code insertion system Wasp [7]. This is achieved at the sacrifice of portability, as discussed earlier. By utilising the JPDA, we intend to provide a system that operates on astandard JVM, and deliver performance com-parable to JVM modification. While it would be reason-able to expect considerreason-able overhead involved in running an application through a debugger, the JPDA usesFull Speed Debugging [10]. This allows applications to run at normal speed, using only the interpreter. When an event of interest occurs, the full debugger is activated for interactive program querying.
5.
PROJECT GOALS
This project intends to produce a mechanism for captur-ing the execution state of a Java application uscaptur-ing the Java Platform Debugging Architecture. By conducting quanti-tative analysis of our system and other strong migration implementations, this project will investigate the following research questions:
1. Is it possible to efficiently track and replicate module state and execution context with the Java Platform Debugging Architecture?
2. What impact does using the JPDA system have on the performance of applications in comparison to other strong migration systems implemented in Java? Due to Java’s native support of transport protocols (eg sock-ets and RMI), this project will not be investigating frame-works for the transfer of objects, but will focus on the mi-gration of the execution context.
6.
METHODOLOGY
The JPDA provides access to data previously unobtainable in a Java application. Upon capturing and handling a fired event, it is possible to access the execution stack, local vari-ables and the point at which execution was suspended. In order to capitalise these features, our mobile object system will be developed in the following way:
Develop software that will:
- run a mobile object in the JPDA
- add a request for stepping events to the mobile object at migration time
- capture the stepping event - thereby suspending exe-cution
- obtain execution stack, variables and point of suspen-sion
- persist object and execution data
- migrate object to destination host using RMI - rebuild object and resume execution of the thread The above approach requires a means of persisting the data obtained via the JPDA for migration to the destination host. This shall be developed as a part of this research project. Additionally processes to rebuild the object with the execu-tion data and recommence at the point of suspension will also be developed. Initial research indicates that the follow-ing approach may provide the basis for resumfollow-ing execution at the correct location.
To recomence execution at the point of suspension, an if
statement, that always evaluates to false, may be placed around previously executed commands, allowing them to be
skipped at re-execution. Insertion of the if statement may be achieved by modifying the objects byte code and utilising the RedfineClasses method [10] provided by the JVMDI.
RedfineClasses allows the substitution of byte code for an object currently executing, with a new byte code definition. Once the object has recommenced, theif statement may be removed to allow normal execution to continue.
The evaluation of the developed framework will focus upon its efficiency in terms of both performance and portability in comparison to existing systems by:
- replicating experiments of existing systems where source code is available
- using experiment data from published systems if the source code is unavailable
- benchmarking developed system against existing ones - comparative analysis of performance and portability. Performance metrics include:
- time taken to pervade and restore both object and execution state data
- general system overhead, a comparison of application running time in our system, and as a standard appli-cation.
- time taken to migrate
- size of both mobile object, and that of the execution data migrated to the destination host
Timeline
Figure 2 shows the intended schedule for our project. It is intended for initial software development to be completed by July, allowing for testing and modification. Similarly, thesis writing will also commence at an early stage, taking into consideration the possibility that further experiments are needed for a comprehensive report.
| Software Development |xxxxxxxxxxx Analysis of Existing | implementations |xxxxxx Testing | xxx xx Experiments | xxxxx xx Thesis Writing | x xx xxxxxxxxxxxx +---|---|---|---|---|---|---| A M J J A S O
Figure 2: Project Time Line
7.
REFERENCES
[1] A. Acharya, M. Ranganathan, and J. Saltz. Sumatra: A language for resource-aware mobile programs. In J. V. Tschudin and C., editors,Mobile Object Systems: Towards the Programmable Internet, pages 111–130. Springer-Verlag, Heidelberg, Germany, 1997. [2] T. Anderson, D. Culler, and D. Patterson. A case for
NOW.IEEE Micro, 15(1):54 – 64, 1995.
[3] S. Bouchenak and D. Hagimont. Pickling threads state in the java system. InThird European Research Seminar on Advances in Distributed Systems
(ERSADS’99),, Madeira Island, Portugal, 1999.http: //sardes.inrialpes.fr/~bouchena/publications/. [4] S. Bouchenak and D. Hagimont. Zero overhead java
thread migration. Technical Report 0261, INRIA, 2002.http:
//sardes.inrialpes.fr/~bouchena/publications/. [5] M. Fuad and M. Oudshoorn. AdJava - automatic
distribution of java applications. In M. Oudshoorn, editor,Twenty-Fifth Australian Computer Science Conference, volume 4, pages 65 – 75, Melbourne, Australia, 2001. Australian Computer Society. [6] A. Fuggetta, G. Picco, and G. Vigna. Understanding
code mobility.IEEE Transactions on Software Engineering, 24(5):342 – 361, 1998.
[7] S. Funfrocken. Transparent migration of java-based mobile agents. In F. H. Kurt Rothermel, editor,
Proceedings of the Second International Workshop on Mobile Agents (MA’98), pages 26–37, Stuttgart, Germany, 1998. Springer-Verlag.
[8] D. M. Geary.Graphic Java 1.2, Mastering the JFC, volume 1 ofJava Series. The Sun Microsystems Inc, Palo Alto, 3rd edition, 1999.
[9] S. Microsystems. Java platform debugger architecture overview, 2000.http://java.sun.com/j2se/1.3/ docs/guide/jpda/jpda.html.
[10] S. Microsystems. The java hotspot virtual machine v1.4.1 white paper, 2002.http://java.sun.com/ products/hotspot/docs/whitepaper/Java_Hotspot_ v1.4.%1/Java_HSpot_WP_v1.4.1_1002_3.html. [11] S. Microsystems. Object serialization: Frequently
asked questions, 2003.http:
//java.sun.com/products/jdk/serialization/faq.
[12] T. Sekiguchi, H. Masuhara, and A. Yonezawa. A simple extension of java language for controllable transparent migration and its portable
implementation. InCoordination Models and Languages, pages 211–226. 1999.
[13] F. Tandiary, S. Kothari, A. Dixit, and E. W. Anderson. Batrun: Utilizing idle workstations for large-scale computing. IEEE Parallel and Distributed Technology: Systems and Applications, 4(2):41–48, 1996.
