Transcript Slides

Portable Support for Transparent
Thread Migration in Java
Eddy Truyen, Bert Robben, Bart
Vanhaute, Tim Coninx, Wouter
Jousen and Pierre Verbaeten
Department Computerwetenschappen, K.U.
Leuven
Review by Brian Wims for ECE 7995, WSU 2001
Introduction
• Mobile Agents Technology
–
–
–
–
Easier to design and maintain distributed systems
Reduces network traffic
Overcomes network latency
Eventually more robust programs
• Java as Mobile Agent Platform
–
–
–
–
Machine independent byte code
Transportable over the net
Transparent migration of data state
Security concepts
Introduction
• Java’s not “Agent Ready”
– Must add Agent capabilities
– Middleware support
•
•
•
•
•
•
Object semantics
Migration mechanisms
Resource management
Execution support
Security
…
Introduction
– No Strong Mobility
• Requires transmission of stack, registers
• Java’s security policy forbids Dynamic inspection of the stack
Problem Statement
• Java does not support Strong Mobility
–
–
–
–
Program State
Data State
Execution State
operand stack
Objective
• Extract Thread state
• Migrate State
• Resume Execution
Approach
• Transform Java Byte Code
– Inserted code blocks with JavaClass
• Capture state
• Restore state
• Unique?
– Does not alter JVM
– Transform prior to execution
Other Approaches
• Source Code Transformation
– Wasp mobile agent
• Extending the JVM
– Sumatra/D`Agents/Ara
• ByteCode Transformation
– run time/preprocessed
Java Thread Overview
• Java Stack Frame
– frame per method call
TopLevel Method call
Java Program
Current
Method
this - pointer
local variable 1
local variable 2
Current Frame
partial result 1
partial result 2
obj ref or call method
argument value 1
Previous
Method
Objects in
program
Next Frame
Other Approaches
• Source Code Transformation
– pre-process the source code
• Insert checksums
–
–
–
–
Backup the thread state in Backup Objects
Contains current method
Last checkpoint
State of the local variables
– Restoration through partial reexecution
– Rebuild Java stack frames
– Update local variables
• 25ms migration time (reexecution)
• 130x increased execution time factor (extra
statements)
• Source code not always available
Other Approaches
• Source Code Transformation
– Programmer controls migration
System.out.println(“bye”);
go (“//ritsuko:2001/JavaGoExecutor”);  migration point
System.out.println(“nice to meed you”)
– Programmer controls “scope”
undock {
go {“//ritsuko:2001/JavaGoExecutor”);
System.out.println(“nice to meet you”);
}
System.out.println(“bye”)
Other Approaches
• Source Code Transformation
– Preprocessed code restores states
void bar( ) {
foo( )
System.out.println(“after foo”);
return;
}
void bar( ) {
TopLevel: for( ; ; ) switch (entryPoint) {
case 0;
foo( );
case 1;
System.out.println(“after foo”);
return;
}
}
Other Approaches
• Source Code Transformation
– Preprocessed code captures local variables
void foo ( ) {
int x = 0;
…. the body of a method
}
void foo (State_X_foo State) {
int x;
if (State = null)
x=0;
else
x=State.x;
try{
… the body of a method…
} catch (NotifyMigration e) {
State = new State_x_foo(this);
State.x=x;
e.Append(State);
throw e;
}
}
Other Approaches
• Extending the JVM
• ThreadState object
–
–
–
–
captures thread state
Parses the Java stack (in native c)
Builds Type Stack in parallel
Determines variable types from Java ByteCode
» istore, aload, …
• Restoration initializes new thread to ThreadObject info
Public final class ThreadStateMangement{
/* Captures the state of the current thread and returns it as a ThreadObject
public static ThreadState capture( );
/* Creates a new Java thread, initializes it with ThreadSt state and starts its
exucution
public static Thread restore(ThreadState Threadst);
}
• 7 ms thread migration (in JVM)
• 10x increased execution time factor
Other Approaches
• Byte Code Transformation (runtime)
– “goto” bytecode instruction instead of “Case” source
code
– uses classLoader to transform bytecode
– method in bytecode  transformed method
– inserted code fragments
•
•
•
•
exception handler for each method
entries from operand stack (copies into local variables)
state object passed to each method (extra parameter)
restoration instructions begin each method
• 1.3-3.2x increased bytecode size
• 20%-50% increased execution time
Other Approaches
• Byte Code Transformation
Java Class File
Class Loader
byte code verifier
JavaClass
Byte code transformations
Interpreter/JIT
Other Approaches
• Byte Code Transformation
class MyClassLoader extends ClassLoader {
private directory;
public MyClassLoader(String dir) {
directory=dir;
}
public synchronized Class loadClass(String name) {
Class c =findLoadedClass(name);
if(c!=null)
return c;
try {
c = findSystemClass(name);
return c;
} catch (ClassNotFoundException e) {
byte [ ] can come from RMI
// keep looking
}
try {
byte[ ] data = getClassData(directory, name);
return defineClass(name, data, 0, data.length( ));
……
ByteCode can be transformed before returning
New Approach
• Byte Code Transformation (preprocessed)
– instrument code in advance to reduce execution time
– agent initiates migration
– captures its own state info
• uses if statement instead of exception method
method {
….
a= foo.method( );
if isCapturing( ) {
store stackframe into Context
store artificial PC (reentry)
return;
}
bytecode inserted
after return
nextstatement( );
exits method to caller
(return vs throw)
New Approach
• pedict 30% bytecode blowup
– affects disk storage
• 27% increased execution time
– with a lot of method calls
Issues
No work on multible threads
How much ByteCode transformation
on java.lang?
No work on external references
• code blow up, execution time, migration time
– no consistent analysis among papers
– factors, # methods, type of applications, …