Abstract:
A method of executing bytecode by means of a secondary interpreter using the services of the primary virtual machine is disclosed. This facilitates the development and execution of long-lived processes that require execution context serialization.

Description:
TECHNICAL FIELD  
         [0001]    The invention relates to the field of computer programmming and processing and more particularly to methods for processing bytecodes within a computer system.  
         BACKGROUND  
         [0002]    Bytecode is currently the dominant type of portable code or mobile code. Portable or mobile code are types of code which permit a program to be run on a variety of different central processing units, such as CPU&#39;s using Windows™ or UNIX™-based or UNIX™-like operating systems, without modification. Bytecode accomplishes this by providing a program to translate the portable code to the code used by the local CPU at runtime. Thus the program is written for an imaginary CPU and this is then translated for the actual CPU at runtime.  
           [0003]    Currently the design of advanced distributed software systems may involve development of long-running processors that require state preservation during asynchronous method invocations. The time interval between invocations may be on the order of magnitude of days or even years. The standard solution in such cases is to use stateful persistent objects and an event-driven execution model. This approach, in the case of complex interaction, tends to be difficult for software development and maintenance because process logic implementation is scattered across multiple event handling methods. Furthermore, such an approach makes it very difficult to implement the process composition. It would therefore be desirable to implement execution context reification to simplify development of such systems and allow program flow of asynchronous events using a synchronous paradigm.  
           [0004]    Currently the most prevalent bytecode formats are Sun Microsystem Inc.&#39;s Java Virtual Machine (JVM) and Microsoft&#39;s Common Language Runtime (CLR). Such systems have a rich functionality to access their Run-Time Type Information (RTTI) using a mechanism called reflection. However these systems do not allow serializing execution state of the process running inside the Virtual Machine. It is therefore desirable to build a bytecode interpreter which has execution context reification mechanisms for these systems.  
         SUMMARY OF INVENTION  
         [0005]    The present invention facilitates development and execution of long-lived processes that require execution context serialization such as applications with asynchronous interaction with the outside world or mobile agents. The method can be implemented in any runtime environment that uses bytecode-based execution file format, such as Sun Microsystem Inc.&#39;s Java Virtual Machine (JVM) and Microsoft&#39;s Common Language Runtime (CLR). The invention provides a secondary bytecode interpreter that executes specially marked methods using services of the Primary Virtual Machine (PVM) such as object management, garbage collecting, multithreading and the like. The process execution context is implemented as first-class-object of the PVM and is used by the secondary interpreter to represent its state. At any moment the execution of the interpreted process can be stopped and the execution context can be serialized and saved to any storage, such as memory, database or file system, or can be sent across the network for process continuation or storage. Execution context can be restored from its serialized form and execution can be continued from the exact point where it was stopped. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0006]    In drawings which illustrate a preferred embodiment of the invention:  
         [0007]    [0007]FIG. 1 is a schematic block diagram showing the structure of the prior art bytecode based execution environment;  
         [0008]    [0008]FIG. 2 is a schematic block diagram showing the structure of the secondary interpreter of the invention implemented as a process executed by the Primary Virtual Machine;  
         [0009]    [0009]FIG. 3 is a schematic block diagram showing the structure of the secondary interpreter of the invention implemented as an external process running outside of the Primary Virtual Machine;  
         [0010]    [0010]FIG. 4 is a schematic flow diagram illustrating the bytecode execution process using the invention;  
         [0011]    [0011]FIG. 5 is a flow chart illustrating the control flow of the secondary interpreter; and  
         [0012]    [0012]FIG. 6 is a schematic flow chart illustrating the Secondary Interpreter lifecycle in case of multiple PVM processes. 
     
    
     DESCRIPTION  
       [0013]    Throughout the following description, specific details are set forth in order to provide a more thorough understanding of the invention. However, the invention may be practiced without these particulars. In other instances, well known elements have not been shown or described in detail to avoid unnecessarily obscuring the invention. Accordingly, the specification and drawings are to be regarded in an illustrative, rather than a restrictive, sense.  
         [0014]    [0014]FIG. 1 illustrates a common bytecode-based execution environment, such as Sun Microsystem Inc.&#39;s Java Virtual Machine (JVM) and Microsoft&#39;s Common Language Runtime (CLR). The Primary Virtual Machine  10  executes all object methods using various service modules such as Heap  12 , Garbage Collector  14 , Bytecode Verifier  16 , Classloaders  18 , etc. The present invention provides a method of bytecode execution when the main execution branch, which represents itself as an asynchronously interrupted process, is interpreted by a secondary interpreter and all side execution branches are executed by the PVM. The secondary interpreter can be implemented as a PVM process as shown in FIG. 2 or as a native code module as shown in FIG. 3.  
         [0015]    As shown in FIG. 2, the secondary interpreter  20  is implemented as a process that runs inside the Primary VM. The Secondary Interpreter  20  executes specially marked object methods using the Primary VM services such as Access to Objects using reflection mechanism, Heap  12 , Garbage Collector  14 , Bytecode Verifier  16  and Classloaders  18 . In FIG. 3, the Secondary Interpreter  20  is implemented as an external process that runs outside of the Primary VM, possibly as a native module.  
         [0016]    The secondary interpreter uses an execution context object that keeps the state of the process. The Execution Context Object is a common object with a set of fields and methods that allow control of execution such as process stopping, resuming, serialization, de-serialization and the like. The main execution branch of the interpreted process consists of a sequence of method invocations, where all such methods are discriminated using different discrimination mechanisms and are executed by the secondary interpreter. Discrimination can be based on different mechanisms, such as special code attributes, method name templates, class or namespace or it can be defined programmatically at runtime. All methods that are not discriminated are considered as side branches and the interpreter delegates their execution using reflection mechanism to the PVM for higher performance. Object management is provided by the PVM and the secondary interpreter updates object state using reflection mechanism during bytecode interpretation.  
         [0017]    The process executed by the secondary interpreter can be interrupted at any point of bytecode interpretation. There are two ways to interrupt the process: from any outside thread accessing the interpreter and execution context methods, or from a process execution thread when the secondary interpreter reaches an interruption point. This interruption point can be defined by a method that is marked by a different discriminator than used to define interpreted methods. When the interpreter is interrupted, it stops bytecode execution and passes control to the method that started the interpreter. After the process interpretation has been stopped, its execution context can be serialized and/or stored or sent across the network and reactivated in its pre-stop state at any time. It is possible to implement various call back methods for the embedded interpreter, such as, but not limited to, method call, field modification, object creation and the like. This mechanism allows detailed control of the process execution by the developer.  
         [0018]    The bytecode execution process using the invention is illustrated in FIG. 4 as follows:  
         [0019]    1. Normal Primary Virtual Machine method PVMM0 activates instance of the Secondary interpreter and passes class name, method name and parameter list to it.  
         [0020]    2. Secondary interpreter loads bytecode for IM1 body in memory, pushes parameters on its process stack and starts interpreting method body.  
         [0021]    3. Method IM1 contains call to method PVMM1 that is not marked as interpretable and execution of the method is delegated to Primary Virtual Machine.  
         [0022]    4. After return from method PVMM1, method IM1 is interpreted until it reaches call to method IM2, which is marked as interpretable.  
         [0023]    5. Secondary interpreter loads bytecode for IM2 body in memory and starts interpreting it.  
         [0024]    6. Secondary interpreter reaches call to method PVMM2 that is not marked as interpretable and execution of the method delegated to Primary Virtual Machine.  
         [0025]    7. Method PVMM2 returns and IM2 continues its execution by Secondary interpreter  
         [0026]    8. Secondary interpreter reaches call to method ATCM1 that is marked as interruption method and returns control to method PVMM0  
         [0027]    9. Method PVMM0 stores state of Secondary interpreter (in memory or in any other device or environment) and continue its normal execution.  
         [0028]    10. New thread in the current PVM process or new PVM process can be started on the same or other machine that has access to the store where Secondary interpreter state is saved.  
         [0029]    11. Method PVMM3 starts its execution. It retrieves and reactivates Secondary interpreter object (or its copy) and continues interpretation passing a value as simulated result of execution of method ATCM1.  
         [0030]    12. Method IM2 accepts value passed from PVMM3 as result of ATCM1 and IM2 continues its execution by Secondary interpreter.  
         [0031]    13. Method IM2 returns and IM1 continues its execution by Secondary interpreter.  
         [0032]    14. Method IM1 returns and Secondary interpreter returns to method PVMM3.  
         [0033]    15. Method PVMM3 continues its execution by Primary Virtual Machine.  
         [0034]    [0034]FIG. 5 by way of a flow chart illustrates the control flow of the secondary interpreter. In FIG. 6 a schematic flow chart illustrates the Secondary Interpreter lifecycle in the case of multiple PVM processes.  
         [0035]    The following pseudo-code illustrates an implementation of the invention  
                                                                                                                                                                                                                                                                                                                                                                       /**        * Class Sample illustrates use of secondary interpreter in a general       scenario        */       public class Sample {                /**            * Execution of this method will be delegated to PVM            */           public void PVMM1( ){                /*Method Body */                }           /**            * Execution of this method will be delegated to PVM            */           public void PVMM2( ){                /*Method Body */                }           /**            * This method is marked by ATCStartSignal exception code            attribute and instead of its                 * execution Secondary interpreter will pass control to the method            that started interpretation                 */           public int ATCM1( ) throws ATCStartSignal{                return 0;// Dummy method body that never will be executed                }           /**            * This method is marked by ATCSignal exception code attribute            * and will be executed by Secondary interpreter            */           public void IM1(String data) throws ATCSignal{                PVMM1( ) ; // 3           IM2( ); // 4           // 13                }           /**            * This method is marked by ATCSignal exception code attribute            * and will be executed by Secondary interpreter            */           public void IM2( ) throws ATCSignal{ // 5                PVMM2( ); // 6           // 7           //This call interrupts execution and passes control back to                method that created the SecondaryInterpreter                int n = ATCM1( ); // 8           // 12           System.out.println(“ATCM1 result = ”+n);                }           /**            * This method creates new instance of SecondaryInterpreter            * defining object, method and parameters values and starts            interpretation                 */           public void PVMM0( ) throws Exception{                Method startMethod = Sample.class.getMethod (“IM1”,new            Class [ ]{String.class});                Sample targetObject = new Sample( );           Object parameters = new Object [ ]{“start”};           SecondaryInterpreter secondaryInterPreter = new            SecondaryInterpreter(targetObject, startMethod, parameters); // 1                // MethodCall object contained information of ATC method call            such as method name,                // target object and values of parameters           MethodCall methodCall = secondaryInterpreter.start( ); // 2           //This call stores state of secondaryInterpreter in some store           secondaryInterpreter.store(“SomeStore”); // 9                }           /**            * This method restores state of secondaryInterpreter and continues            interpretation                 * passing simulated result of ATCM1 to IM2            */           public void PVMM3( ) throws Exception{                // 11           SecondaryInterpreter secondaryInterpreter = new            SecondaryInterpreter( );                secondaryInterpreter.read(“SomeStore”);           Object atcMethodResult = new Integer(10);           MethodCall methodCall =                secondayInterpreter.resume(atcMethodResult); // 14                // 15                }            }                  
 
         [0036]    As will be apparent to those skilled in the art in the light of the foregoing disclosure, many alterations and modifications are possible in the practice of this invention without departing from the spirit or scope thereof. Accordingly, the scope of the invention is to be construed in accordance with the substance defined by the following claims.