Mohammad Mustafeezur Rahman (Xavient Information S

• Jul 27th, 2006

 

YES!The main issue when building Java thread serialization is toaccess the thread's execution state, a state that is internal to theJava virtual machine (JVM) and not directly accessible to Javaprogrammers. A possible solution is to extend the JVM with newmechanisms that capture a thread state in a serialized and portableform, and later restore a thread from its serialized state,e.g., Sumatra [1], Merpati [10], ITS [2] and CIA [6]. Anothersolution is based on a pre-processor that transforms thread’sapplication code prior to execution in order to add statements thatfollow thread’s execution and manage its state capture,e.g., Wasp [5], JavaGo [9], Brakes [11] and JavaGoX [8]. TheseJava thread serialization mechanisms are characterized by fourproperties:• The completeness of the accessed thread state.• The genericity of thread serialization: its ability to adapt todifferent uses, e.g., mobility, persistence.• The portability of the serialization mechanism acrossdifferent Java platforms.• The efficiency of the mechanism, i.e., its impact on theperformance of thread execution.Regarding the existing solutions, the thread serialization systemsbased on a JVM-level implementation verify the completenessrequirement but lack in efficiency and portability. And the threadserialization systems proposed at the application level are portablebut they are neither efficient nor complete. Furthermore, exceptMerpati and ITS, all the existing implementations propose Javathread serialization mechanisms that are restricted to threadmobility. Merpati allows Java threads to benefit from bothmobility and persistence but it lacks in genericity because theproposed mobility/persistence services can not be adapted toapplications' needs; while ITS proposes a generic implementationof Java thread serialization