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 this - pointer local variable 1 local variable 2 partial result 1 partial result 2 obj ref or call method argument value 1 Current Frame Next Frame Current Method Previous Method TopLevel Method call Java Program Objects in program

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 x increased bytecode size 20%-50% increased execution time

Other Approaches Byte Code Transformation Java Class FileClass Loader JavaClass Byte code transformations byte code verifierInterpreter/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) { // keep looking } try { byte[ ] data = getClassData(directory, name); return defineClass(name, data, 0, data.length( )); …… byte [ ] can come from RMI 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; } nextstatement( ); bytecode inserted after return 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, …