Patent Publication Number: US-6704923-B1

Title: System and method for pre-verification of stack usage in bytecode program loops

Description:
This application is a continuation of patent application Ser. No. 08/858,793, filed May 19, 1997, now U.S. Pat. No. 6,075,940, which was a division of patent application Ser. No.08/359,882, filed: Dec. 20, 1994, now U.S. Pat. No. 5,668,999. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to the use of computer software on multiple computer platforms which use distinct underlying machine instruction sets, and more specifically to a method of verifying the integrity of computer software obtained from a network server or other source. 
     2. Prior Art 
     As represented generally in FIG. 1, in a typical prior art networked computer system  100 , a first computer  102  may download a computer program  103  residing on a second computer  104 . In this example, the first user node  102  will typically be a user workstation having a central processing unit  106 , a user interface  108 , a primary memory  110  (e.g., random access memory) for program execution, a secondary memory  112  (e.g., a hard disc) for storage of an operating system  113 , programs, documents and other data, and a modem or other communication interface  114  for connecting to a computer network  120  such as the Internet, a local area network or a wide area network. The computers  102  and  104  are often called “nodes on the network” or “network nodes.” 
     The second computer  104  will often be a network server, but may be a second user workstation, and typically would contain the same basic array of computer components as the first computer. 
     In the prior art, after the first computer  102  downloads a copy of a computer program  103  from the second computer  104 , there are essentially no standardized tools available to help the user of the first computer  102  to verify the integrity of the downloaded program  103 . In particular, unless the first computer user studies the source code of the downloaded program, it is virtually impossible using prior art tools to determine whether the downloaded program  103  will underflow or overflow its stack, or whether the downloaded program  103  will violate files and other resources on the user&#39;s computer. 
     A second issue with regard to downloading computer software from one computer to another concerns transferring computer software between computer platforms which use distinct underlying machine instruction sets. There are some prior art examples of platform independent computer programs and platform independent computer programming languages. What the prior art lacks are reliable and automated software verification tools for enabling recipients of such software to verify the integrity of transferred platform independent computer software obtained from a network server or other source. 
     SUMMARY OF THE INVENTION 
     The present invention verifies the integrity of computer programs written in a bytecode language, to be commercialized as the OAK language, which uses a restricted set of data type specific bytecodes. All the available source code bytecodes in the language either (A) are stack data consuming bytecodes that have associated data type restrictions as to the types of data that can be processed by each such bytecode, (B) do not utilize stack data but affect the stack by either adding data of known data type to the stack or by removing data from the stack without regard to data type, or (C) neither use stack data nor add data to the stack. 
     The present invention provides a verifier tool and method for identifying, prior to execution of a bytecode program, any instruction sequence that attempts to process data of the wrong type for such a bytecode or if the execution of any bytecode instructions in the specified program would cause underflow or overflow of the operand stack, and to prevent the use of such a program. 
     The bytecode program verifier of the present invention includes a virtual operand stack for temporarily storing stack information indicative of data stored in a program operand stack during the execution a specified bytecode program. The verifier processes the specified program by sequentially processing each bytecode instruction of the program, updating the virtual operand stack to indicate the number, sequence and data types of data that would be stored in the operand stack at each point in the program. The verifier also compares the virtual stack information with data type restrictions associated with each bytecode instruction so as to determine if the operand stack during program execution would contain data inconsistent with the data type restrictions of the bytecode instruction, and also determines if any bytecode instructions in the specified program would cause underflow or overflow of the operand stack. 
     To avoid detailed analysis of the bytecode program&#39;s instruction sequence flow, and to avoid verifying bytecode instructions multiple times, all points (called multiple-entry points) in the specified program that can be can be immediately preceded in execution by two or more distinct bytecodes in the program are identified. In general, at least one of the two or more distinct bytecodes in the program will be a jump/branch bytecode. During processing of the specified program, the verifier takes a “snapshot” of the virtual operand stack immediately prior to each multiple-entry point (i.e., subsequent to any one of the preceding bytecode instructions), compares that snapshot with the virtual operand stack state after processing each of the other preceding bytecode instructions for the same multiple-entry point, and generates a program fault if the virtual stack states are not identical. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention, wherein: 
     FIG. 1 depicts two computers interconnected via a network. 
     FIG. 2 depicts two computers interconnected via a network, at least one of which includes a bytecode program verifier in accordance with the present invention. 
     FIG. 3 depicts data structures maintained by a bytecode verifier during verification of a bytecode program in accordance with the present invention. 
     FIGS. 4A-4G represent a flow chart of the bytecode program verification process in the preferred embodiment of the present invention. 
     FIG. 5 represents a flow chart of the bytecode program interpreter process in the preferred embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to those embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. 
     Referring now to a distributed computer system  200  as shown in FIG. 2, a first computer node  202  is connected to a second computer node  204  via a computer communications network such as the Internet  220 . The first computer node  202  includes a central processing unit  206 , a user interface  208 , primary memory (RAM)  210 , secondary memory (disc storage)  212 , and a modem or other communication interface  214  that connects the first computer node  202  to the computer communication network  220 . The disc storage  212  stores programs for execution by the processor  206 , at least one of which is a bytecode program  221  which is of executable form. For the purposes of this description, it will be assumed that the first computer node  202  receives the bytecode program  221  from the second computer node  204  via the computer communications network  220  using file transfer protocols well known to those skilled in the art. 
     In the preferred embodiment, the bytecode program is written as an OAK application, which when compiled or Interpreted will result in a series of executable instructions. A listing of all the source code bytecode instructions in the OAK instruction set is provided in Table 1. The OAK instruction set is characterized by bytecode instructions that are data type specific. Specifically, the OAK instruction set distinguishes the same basic operation on different primitive data types by designating separate opcodes. 
     Accordingly, a plurality of bytecodes are included within the instruction set to perform the same basic function (for example to add two numbers), with each such bytecode being used to process only data of a corresponding distinct data type. In addition, the OAK instruction set is notable for instructions not included. For instance, there are no “computed goto” instructions in the OAK language instruction set, and there are no instructions for modifying object references or creating new object references (other than copying an existing object reference). These two restrictions on the OAK instruction set, as well as others, help to ensure that any bytecode program which utilizes data in a manner consistent with the data type specific instructions in the OAK instruction set will not violate the integrity of a user&#39;s computer system. 
     In the preferred embodiment, the available data types are integer, long integer, short integer (16 bit signed integer), single precision floating point, double precision floating point, byte, character, and object pointer (sometimes herein called an object reference). The “object reference” data type includes a virtually unlimited number of data subtypes because each “object reference” data type can include an object class specification as part of the data type. In addition, constants used in programs are also data typed, with the available constant data types in the preferred embodiment comprising the data types mentioned above, plus class, fieldref, methodref, string, and Asciz, all of which represent two or more bytes having a specific purpose. 
     The few bytecodes that are data type independent perform stack manipulation functions such as (A) duplicating one or more words on the stack and placing them at specific locations within the stack, thereby producing more stack items of known data type, or (B) clearing one or more items from the stack. A few other data type independent bytecode do not utilize any words on the stack and leave the stack unchanged, or add words to the stack without utilizing any of the words previously on the stack. 
     These bytecodes do not have any data type restrictions with regard to the stack contents prior to their execution, and all but a few modify the stack&#39;s contents and thus affect the program verification process. 
     The second computer node  204 , assumed here to be configured as a file or other information server, includes a central processing unit  218 , a user interface  228 , primary memory (RAM)  222 , secondary memory (disc storage)  224 , and a modem or other communication interface  234  that connects the second computer node to the computer communication network  220 . The disc storage  224  stores programs for execution by the processor  218  and/or distribution to other computer nodes. 
     The first and second computer nodes  202  and  204  may utilize different computer platforms and operating systems  236 ,  237  such that object code programs executed on either one of the two computer nodes cannot be executed on the other. For instance, the server node  204  might be a Sun Microsystems computer using a Unix operating system while the user workstation node  202  may be an IBM compatible computer using an 80486 microprocessor and a Microsoft DOS operating system. Furthermore, other user workstations coupled to the same network and utilizing the same server  204  might use a variety of different computer platforms and a variety of operating systems. 
     In the past, a server  204  used for distributing software on a network having computers of many types would store distinct libraries of software for each of the distinct computer platform types (e.g., Unix, Windows, DOS, Macintosh, etc.). Thus, different versions of the same computer program might be stored in each of the libraries. However, using the present invention, many computer programs could be distributed by such a server using just a single, bytecode version of the program. 
     As shown in FIG. 2, the first computer node  202  stores in its secondary memory  212  a bytecode verifier program  240  for verifying the integrity of specified bytecode programs and a bytecode interpreter  242  for executing specified bytecode programs. Alternately, or in addition, the first computer node  202  may store a bytecode compiler  244  for converting a verified bytecode program into an object code program for more efficient execution of the bytecode program  221  than by the interpreter  244 . 
     The bytecode verifier  240  is an executable program which verifies operand data type compatibility and proper stack manipulations in a specified bytecode (source) program  221  prior to the execution of the bytecode program  221  by the processor  206  under the control of the bytecode interpreter  242 . Each bytecode program  103  has an associated verification status value  245  that is initially set to False when the program is downloaded from another location. The verification status value  245  for the program is set to True by the bytecode verifier  240  only after the program has been verified not to fail any of the data type and stack usage tests performed by the verifier  240 . 
     During normal execution of a program by an interpreter, the interpreter must continually monitor the operand stack for overflows (i.e., adding more data to the stack than the stack can store) and underflows (i.e., attempting to pop data off the stack when the stack is empty). Such stack monitoring must normally be performed for all instructions that change the stack&#39;s status (which includes most all instructions). For many programs, stack monitoring instructions executed by the interpreter account for approximately 80% of the execution time of an interpreted computed program. 
     In addition, the downloaded bytecode program may contain errors involving the data types of operands not matching the data type restrictions of the instructions using those operands, which may cause the program to be fail during execution. Even worse, a bytecode program might attempt to create object references (e.g., by loading a computed number into the operand stack and then attempting to use the computed number as an object handle) and to thereby breach the security and/or integrity of the user&#39;s computer. 
     Use of the bytecode verifier  240  in accordance with the present invention enables verification of a bytecode program&#39;s integrity and allows the use of an interpreter  242  which does not execute the usual stack monitoring instructions during program execution, thereby greatly accelerating the program interpretation process. 
     The Bytecode Program Verifier 
     Referring now to FIG. 3, the execution of th e bytecode program verifier  240  will be explained in conjunction with a particular bytecode program  340 . The verifier  240  uses a few temporary data structures to store information it needs during the verification process. In particular, the verifier  240  uses a stack counter  342 , a virtual stack  344 , a virtual local variable array  345 , and a stack snapshot storage structure  346 . 
     The stack counter  342  is updated by the verifier  240  as it keeps track of the virtual stack manipulations so as to reflect the current number of virtual stack  320  entries. 
     The virtual stack  344  stores data type information regarding each datum that will be stored by the bytecode program  340  in the operand stack during actual execution. In the preferred embodiment, the virtual stack  344  is used in the same way as a regular stack, except that instead of storing actual data and constants, the virtual stack  344  stores a data type indicator value for each datum that will be stored in the operand stack during actual execution of the program. Thus, for instance, if during actual execution the stack were to store three values: 
     HandleToObjectA 
     5 
     1 
     the corresponding virtual stack entries will be 
     R 
     I 
     I 
     where “R” in the virtual stack indicates an object reference and each “I” in the virtual stack indicates an integer. Furthermore, the stack counter  342  in this example would store a value of 3, corresponding to three values being stored in the virtual stack  344 . 
     Data of each possible data type is assigned a corresponding virtual stack marker value, for instance: integer (I), long integer (L), single precision floating point number (F), double precision floating point number (D), byte (B), short (S), and object reference (R). The marker value for an object reference will often include an object class value (e.g., R:point, where “point” is an object class). 
     The virtual local variable array  345  serves the same basic function as the virtual stack  344 . That is, it is used to store data type information for local variables used by the specified bytecode program. Since data is often transferred by programs between local variables and the operand stack, the bytecode instructions performing such data transfers and otherwise using local variables can be checked to ensure that the local variables accessed by each bytecode instruction are consistent with the data type usage restrictions on those bytecode instructions. 
     While processing the specified bytecode program, for each datum that would be popped off the stack for processing by a bytecode instruction, the verifier pops off the same number of data type value off the virtual stack  342  and compares the data type values with the data type requirements of the bytecode. For each datum that would be pushed onto the stack by a bytecode instruction, the verifier pushes onto the virtual stack a corresponding data type value. 
     One aspect of program verification in accordance with present invention is verification that the number and data type of the operands in the operand stack status is identical every time a particular instruction is executed. If a particular bytecode instruction can be immediately preceded in execution by two or more different instructions, then the virtual stack status immediately after processing of each of those different instructions must be compared. Usually, at least one of the different preceding instructions will be a conditional or unconditional jump or branch instruction. A corollary of the above “stack consistency” requirement is that each program loop must not result in a net addition or reduction in the number of operands stored in the operand stack. 
     The stack snapshot storage structure  346  is used to store “snapshots” of the stack counter  342  and virtual stack  344  to enable efficient comparison of the virtual stack status at various points in the program. Each stored stack snapshot is of the form: 
     
       
         SC, DT 1 , DT 2 , DT 3 , . . . , DTn 
       
     
     where SC is the stack counter value, DT 1  is the first data type value in the virtual operand stack, DT 2  is the second data type value in the virtual operand stack, and so on through DTn which is the data type value for the last possible item in the virtual operand stack. 
     The stack snapshot storage structure  346  is bifurcated into a directory portion  348  and a snapshot storage portion  350 . The directory portion  348  is used to store target instruction identifiers (e.g., the absolute or relative address of each target instruction) while the snapshot portion  350  is used to store virtual stack  344  snapshots associated with the target instruction identifiers. 
     “Target” instructions are defined to be all bytecode instructions that can be the destination of a jump or branch instruction. For example, a conditional branch instruction includes a condition (which may or may not be satisfied) and a branch indicating to which location (target) in the program the execution is “jump” in the event the condition is satisfied. In evaluating a conditional jump instruction, the verifier  300  utilizes the stack snapshot storage structure  346  to store both the identity of the target location (in the directory portion  348 ) and the status of the virtual stack  344  (in the snapshot portion  350 ) just before the jump. The operation of the stack snapshot storage structure  346  will be explained in greater detail below in conjunction with the description of the execution of the bytecode verifier program. 
     As was described previously, the bytecode program  350  includes a plurality of data type specific instructions, each of which is evaluated by the verifier  300  of the present invention. The bytecode program  350  includes instructions for stack manipulations  352  and  354  (push integer onto the stack and pop integer from the stack respectively), a forward jump  356  and its associated target  364 , a backwards jump  366  and its associated target  362 , and a do loop  358  and its associated end  360  (which may be an unconditional or conditional branch instruction, depending on the type of do loop). Since the verifier  240  of the preferred embodiment of the present invention only seeks to verify stack manipulations and data type compatibilities, the operation of the bytecode verifier can be explained using this representative set of instructions. 
     Referring now to FIGS. 4A-4G, and Appendix 1, the execution of the bytecode verifier program  240  will be described in detail. Appendix 1 lists a pseudocode representation of the verifier program. The pseudocode used in Appendix 1 is, essentially, a computer language using universal computer language conventions. While the pseudocode employed here has been invented solely for the purposes of this description, it is designed to be easily understandable by any computer programmer skilled in the art. 
     As shown in FIG. 4A, the downloaded bytecode program is loaded ( 400 ) into the bytecode verifier  300  for processing. The verifier  300  creates ( 402 ) the virtual stack  344  and creates the virtual local variable array  345  by designating arrays of locations in memory to store operand and local variable data type information. Similarly, the verifier creates ( 404 ) the stack snapshot storage structure by designating an array of locations in memory to store snapshot information. Finally, the verifier designates ( 406 ) a register to act as a stack counter  342  for keeping track of the number of virtual stack entries. 
     A first pass is made through the bytecode program in order to extract target information associated with conditional and unconditional jumps and loop instructions. In this first pass the verifier  300  sequentially processes all the instructions (steps  408 ,  410 ,  412 ), and for each instruction that is a conditional or unconditional jump (step  414 ) a representation of the target location for the jump is stored (step  416 ) in the directory portion  348  of the stack snapshot storage structure  346 , unless (step  418 ) the target location has already been stored in the directory  348 . For instance, the absolute or relative address of the target instruction may be stored in the next available slot of the directory  348 . All other types of bytecode instructions are ignored on this first pass. 
     After all the instructions in the program have been processed, the directory  348  is preferably sorted to put the target locations noted in the directory in address sequential order. 
     Referring again to FIG. 3, for the purposes illustration the stack snapshot storage structure  346  has been loaded with the information which would have been stored in the directory portion  348  as if the first pass of the verification had been completed based on the bytecode instructions shown in bytecode program  350 . Specifically, the directory portion has been loaded with the addresses associated with all of the targets of the conditional and unconditional jumps resident in the bytecode program. 
     Referring now to FIG. 4B, a second pass through the bytecode program is initiated in order to verify proper use of the operand stack and of data types by the bytecode program. The first instruction of the bytecode program is selected ( 430 ) and the verifier first checks ( 432 ) to see if the address for the selected instruction has been stored in the directory portion  348  of the stack snapshot storage structure  346  in the first pass described above. 
     If the address of the selected instruction is in the directory  348 , indicating that the selected instruction is the target of a conditional or un-conditional jump, the verifier checks ( 434 ) to see if an associated stack snapshot has been stored in the snapshot portion  350  of the stack snapshot storage structure  346 . If a stack snapshot has not been stored (indicating that the instruction is a target of a backward jump), then the contents of the virtual stack and the stack counter are stored ( 436 ) in the stack snapshot storage structure  346 . The snapshot contains information on the status of the virtual stack just before the execution of the instruction being processed, including a data type value for each datum that has been pushed onto the stack. 
     If a stack snapshot has been stored for the currently selected instruction (indicating that a jump instruction associated with this target instruction has already been processed), then the verifier compares ( 438 ) the virtual stack snapshot information stored in the snapshot portion  350  of the stack snapshot storage structure  346  for the currently selected instruction with the current state of the virtual stack. If the comparison shows that the current state and the snapshot do not match, then an error message or signal is generated ( 440 ) identifying the place in the bytecode program where the stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current virtual stack and snapshot do not contain the same number or types of entries. The verifier will then set a verification status value  245  for the program to false, and abort ( 442 ) the verification process. Setting the verification status value  245  for the program to false prevents execution of the program by the bytecode interpreter  242  (FIG.  2 ). 
     If the current virtual stack and the stored stack snapshot for the current instruction match ( 438 ), then the verifier will continue the verification process and analyze the individual instruction, starting at step  450 , as described below. 
     If the address of the currently selected instruction is not found within the directory portion  348  of the stack snapshot storage structure  346  or if a stack status mismatch is not detected, then the verifier performs selected ones of a series of checks on the instruction depending on the particular instructions stack usage and function. 
     Referring to FIG. 4C, the first check to be performed concerns instructions that pop data from the operand stack. If the currently selected instruction pops data from the stack ( 450 ), the stack counter is inspected ( 452 ) to determine whether there is sufficient data in the stack to satisfy the data pop requirements of the instruction. 
     If the operand stack has insufficient data ( 452 ) for the current instruction, that is called a stack underflow, in which case an error signal or message is generated ( 454 ) identifying the place in the program that the stack underflow was detected. In addition, the verifier will then set a verification status value  245  for the program to false, and abort ( 456 ) the verification process. 
     If no stack underflow condition is detected, the verifier will compare ( 458 ) the data type code information previously stored in the virtual stack with the data type requirements (if any) of the currently selected instruction. For example, if the opcode of the instruction being analyzed calls for an integer add of a value popped from the stack, the verifier will compare the operand information of the item in the virtual stack which is being popped to make sure that is of the proper data type, namely integer. If the comparison results in a match, then the verifier deletes ( 460 ) the information from the virtual stack associated with the entry being popped and updates the stack counter  342  to reflect the number of entries popped from the virtual stack  344 . 
     If a mismatch is detected ( 458 ) between the stored operand information in the popped entry of the virtual stack  344  and the data type requirements of the currently selected instruction, then a message is generated ( 462 ) identifying the place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value  245  for the program to false and abort ( 456 ) the verification process. This completes the pop verification process. 
     Referring to FIG. 4D, If the currently selected instruction pushes data onto the stack ( 470 ), the stack counter is inspected ( 472 ) to determine whether there is sufficient room in the stack to store the data the selected instruction will push onto the stack. If the operand stack has insufficient room to store the data to be pushed onto the stack by the current instruction ( 472 ), that is called a stack overflow, in which case an error signal or message is generated ( 474 ) identifying the place in the program that the stack underflow was detected. In addition, the verifier will then set a verification status value  245  for the program to false, and abort ( 476 ) the verification process. 
     If no stack overflow condition is detected, the verifier will add ( 478 ) an entry to the virtual stack indicating the type of data (operand) which is to be pushed onto the operand stack (during the actual execution of the program) for each datum to be pushed onto the stack by the currently selected instruction. This information is derived from the data type specific opcodes utilized in the bytecode program of the preferred embodiment of the present invention. The verifier also updates the stack counter  342  to reflect the added entry or entries in the virtual stack. This completes the stack push verification process. 
     Referring to FIG. 4E, if the currently selected instruction causes a conditional or unconditional jump or branch forward in the program beyond the ordinary sequential step operation (step  480 ) the verifier will first check ( 482 ) to see if a snapshot for the target location of the jump instruction is stored in the stack snapshot storage structure  346 . If a stack snapshot has not been stored, then the virtual stack configuration (subsequent to any virtual stack updates associated with the jump) is stored ( 484 ) in the stack snapshot storage structure  346  at a location associated with the target program location. Note that any stack pop operations associated with the jump will have already been reflected in the virtual stack by the previously executed step  460  (see FIG. 4C) . 
     If a stack snapshot has been stored (indicating that another entry point associated with this target instruction has already been processed), then the verifier compares ( 486 ) the virtual stack snapshot information stored in the snapshot portion  340  of the stack snapshot storage structure  346  with the current state of the virtual stack. If the comparison shows that the current state and the snapshot do not match, then an error message is generated ( 488 ) identifying the place in the bytecode program where the stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current virtual stack and snapshot do not contain the same number or types of entries. Furthermore, a mismatch will arise if one or more data type values in the current virtual stack do not match corresponding data type values in the snapshot. The verifier will then set a verification status value  245  for the program to false and abort ( 490 ) the verification process. If a stack status match is detected at step  486 , then the verifier continues processing at step  500  (FIG. 4F) . 
     Referring to FIG. 4F, if the currently selected instruction causes a conditional or unconditional jump or branch backward in the program (step  500 ) then the verifier compares ( 502 ) the virtual stack snapshot information stored in the snapshot portion  340  of the stack snapshot storage structure  346  associated with the target of the backward jump (which has already been stored in step  436 ) with the current state of the virtual stack. If the comparison shows that the current state and the snapshot do not match, then an error message is generated ( 504 ) identifying the place in the bytecode program where the stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current virtual stack and snapshot do not contain the same number or types of entries or if any data type entry in the current virtual stack does not match the corresponding data type entry in the snapshot. The verifier will then set a verification status value  245  for the program to false and abort ( 506 ) the verification process. 
     If a stack status match is detected (at step  502 ) or if the instruction is not a backward jump (at step  500 ), then the verifier continues processing at step  510 . 
     If the currently selected instruction reads data from a local variable ( 510 ), the verifier will compare ( 512 ) the data type code information previously stored in the corresponding virtual local variable with the data type requirements (if any) of the currently selected instruction. If a mismatch is detected ( 512 ) between the data type information stored in the virtual local variable and the data type requirements of the currently selected instruction, then a message is generated ( 514 ) identifying the place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value  245  for the program to false and abort ( 516 ) the verification process. 
     If the currently selected instruction does not read data from a local variable ( 510 ) or the data type comparison at step  512  results in a match, then the verifier continues processing the currently selected instruction at step  520 . 
     Referring to FIG. 4G, if the currently selected instruction stores data into a local variable ( 520 ), the corresponding virtual local variable is inspected ( 522 ) to determine whether it stores a data type value. If the virtual local variable does store a data type value (indicating that data has been previously stored in the local variable), the verifier compares the data type information in the virtual local variable with the data type associated with the currently selected bytecode instruction ( 524 ). If a mismatch is detected ( 524 ) between the data type information stored in the virtual local variable and the data type requirements of the currently selected instruction, then a message is generated ( 526 ) identifying the place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value  245  for the program to false and abort ( 528 ) the verification process. 
     If the currently selected instruction does not store data into a local variable ( 520 ) processing for the currently selected instruction is completed. If the currently selected instruction stores data into a local variable, but the virtual local variable does not store a data type value (indicating that no instruction which would store data in the local variable has yet been processed by the verifier), then the data type associated with the selected bytecode instruction is stored in the virtual local variable (step  530 ). 
     Next, the verifier checks ( 540 ) to see if this is the last instruction in the bytecode program  340  to be processed. If more instructions remain to be processed, then the verifier loads ( 542 ) the next instruction, and repeats the verification process starting at step  432 . If no more instructions are to be processed, then the verifier will then set a verification status value  245  for the program to True ( 544 ), signaling the completion of the verification process. 
     Bytecode Interpreter 
     Referring to flow chart in FIG.  5  and Appendix 2, the execution of the bytecode interpreter  242  will be described. Appendix 2 lists a pseudocode representation of the bytecode interpreter. 
     After a specified bytecode program has been received or otherwise selected ( 560 ) as a program to be executed, the bytecode program interpreter  242  calls ( 562 ) the bytecode verifier  240  to verify the integrity of the specified bytecode program. The bytecode verifier is described above. 
     If the verifier returns a “verification failure” value ( 564 ), the attempt to execute the specified bytecode program is aborted by the interpreter ( 566 ). 
     If the verifier  242  returns a “Verification Success” value ( 564 ), the specified bytecode program is linked ( 568 ) to resource utility programs and any other programs, functions and objects that may be referenced by the program. Such a linking step is a conventional pre-execution step in many program interpreters. Then the linked bytecode program is interpreted and executed ( 570 ) by the interpreter. The bytecode interpreter of the present invention does not perform any operand stack overflow and underflow checking during program execution and also does not perform any data type checking for data stored in the operand stack during program execution. These conventional stack overflow, underflow and data type checking operations can be skipped by the present invention because the interpret has already verified that errors of these types will not be encountered during program execution. 
     The program interpreter of the present invention is especially efficient for execution of bytecode programs having instruction loops that are executed many times, because the operand stack checking instructions are executed only once for each bytecode in each such instruction loop in the present invention. In contrast, during execution of a program by a convention interpreter, the interpreter must continually monitor the operand stack for overflows (i.e., adding more data to the stack than the stack can store) and underflows (i.e., attempting to pop data off the stack when the stack is empty). Such stack monitoring must normally be performed for all instructions that change the stack&#39;s status (which includes most all instructions). For many programs, stack monitoring instructions executed by the interpreter account for approximately 80% of the execution time of an interpreted computed program. As a result, the interpreter of the present invention will often execute programs at two to five times the speed of a conventional program interpreter running on the same computer. 
     The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents. 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 BYTECODES IN OAK LANGUAGE 
               
            
           
           
               
               
            
               
                 INSTRUCTION NAME 
                 SHORT DESCRIPTION 
               
               
                   
               
               
                 aaload 
                 load object reference from array 
               
               
                 aastore 
                 store object reference into object reference 
               
               
                   
                 array 
               
               
                 aconst_null 
                 push null object 
               
               
                 aload 
                 load local object variable 
               
               
                 areturn 
                 return object reference from function 
               
               
                 arraylength 
                 get lenth of array 
               
               
                 astore 
                 store object reference into local variable 
               
               
                 astore_&lt;n&gt; 
                 store object reference into local variable 
               
               
                 athrow 
                 throw exception 
               
               
                 bipush 
                 push one-byte signed integer 
               
               
                 breakpoint 
                 call breakpoint handler 
               
               
                 catchsetup 
                 set up exception handler 
               
               
                 catchteardown 
                 reset exception handler 
               
               
                 checkcast 
                 make sure object is of a given type 
               
               
                 df2 
                 convert double floating point number to single 
               
               
                   
                 precision floating point number 
               
               
                 d2i 
                 convert double floating point number to integer 
               
               
                 d2l 
                 convert double floating point number to long 
               
               
                   
                 integer 
               
               
                 dadd 
                 add double floating point numbers 
               
               
                 daload 
                 load double floating point number from array 
               
               
                 dastore 
                 store double floating point number into array 
               
               
                 dcmpg 
                 compare two double floating point numbers 
               
               
                   
                 (return 1 on incomparable) 
               
               
                 dcmpl 
                 compare two double floating point numbers 
               
               
                   
                 (return −1 on incomparable) 
               
               
                 dconst_&lt;d&gt; 
                 push double floating point number 
               
               
                 ddiv 
                 divide double floating point numbers 
               
               
                 dload 
                 load double floating point number from local 
               
               
                   
                 variable 
               
               
                 dload_&lt;n&gt; 
                 load double floating point number from local 
               
               
                   
                 variable 
               
               
                 dmod 
                 perform modulo function on double floating 
               
               
                   
                 point numbers 
               
               
                 dmul 
                 miltiply double floating point numbers 
               
               
                 dneg 
                 negate double floating point number 
               
               
                 dreturn 
                 return double floating point number from 
               
               
                   
                 function 
               
               
                 dstore 
                 store double floating point number into local 
               
               
                   
                 variable 
               
               
                 dstore_&lt;n&gt; 
                 store double floating point number into local 
               
               
                   
                 variable 
               
               
                 dsub 
                 subtract double floating point numbers 
               
               
                 dup 
                 duplicate top stack word 
               
               
                 dup2 
                 duplicate top two stack words 
               
               
                 dup2_×1 
                 duplicate top two stack words and put two 
               
               
                   
                 down 
               
               
                 dup2_×2 
                 duplicate top two stack words and put three 
               
               
                   
                 down 
               
               
                 dup_×1 
                 dulicate top stack word and put two down 
               
               
                 dup_×2 
                 duplicate top stack word and put three down 
               
               
                 f2d 
                 convert single precision floating point number 
               
               
                   
                 to double floating point number 
               
               
                 f2i 
                 convert single precision floating point number 
               
               
                   
                 to integer 
               
               
                 f2l 
                 convert Single precision floating point number 
               
               
                   
                 to long integer 
               
               
                 fadd 
                 add single precision floating point numbers 
               
               
                 faload 
                 load single precision floating point number 
               
               
                   
                 from array 
               
               
                 fastore 
                 store into single precision floating point 
               
               
                   
                 number array 
               
               
                 fempg 
                 compare single precision floating point 
               
               
                   
                 numbers (return 1 on incomparable) 
               
               
                 fempl 
                 compare Single precision floating point 
               
               
                   
                 numbers (return −1 on incomparable) 
               
               
                 fconst_&lt;f&gt; 
                 push single precision floating point number 
               
               
                 fdiv 
                 divide single precision floating point numbers 
               
               
                 fload 
                 load single precision floating point number 
               
               
                   
                 from local variable 
               
               
                 fload_&lt;n&gt; 
                 load single precision floating point number 
               
               
                   
                 from local variable 
               
               
                 fmod 
                 perform modulo function on single precision 
               
               
                   
                 floating point numbers 
               
               
                 fmul 
                 multiply single precision floating point 
               
               
                   
                 numbers 
               
               
                 fneg 
                 negate single precision floating point number 
               
               
                 freturn 
                 return single precision floating point number 
               
               
                   
                 from function 
               
               
                 fstore 
                 store single precision floating point number 
               
               
                   
                 into local variable 
               
               
                 fstore_&lt;n&gt; 
                 store single precision floating point number 
               
               
                   
                 into local variable 
               
               
                 fsub 
                 subtract single precision floating point numbers 
               
               
                 getfield 
                 fetch field from object 
               
               
                 getstatic 
                 set static field from class 
               
               
                 goto 
                 branch always 
               
               
                 i2d 
                 convert integer to double floating point number 
               
               
                 i2f 
                 convert integer to single precision floating 
               
               
                   
                 point number 
               
               
                 i2l 
                 convert integer to long integer 
               
               
                 iadd 
                 add integers 
               
               
                 iaload 
                 load integer from array 
               
               
                 iand 
                 boolean AND two integers 
               
               
                 iastore 
                 store into integer array 
               
               
                 iconst_&lt;n&gt; 
                 push integer 
               
               
                 iconst_m1 
                 push integer constant minus 1 
               
               
                 idiv 
                 integer divide 
               
               
                 if_acmpeq 
                 branch if objects same 
               
               
                 if_acmpne 
                 branch if objects not same 
               
               
                 if_icmpeq 
                 branch if integers equal 
               
               
                 if_icmpge 
                 branch if integer greater than or equal to 
               
               
                 if_icmpgt 
                 branch if integer greater than 
               
               
                 if_icmple 
                 branch if integer less than or equal to 
               
               
                 if_icmpit 
                 branch if integer less than 
               
               
                 if_icmpne 
                 branch if integers not equal 
               
               
                 ifeq 
                 branch if equal to 0 
               
               
                 ifge 
                 branch if greater than or equal to 0 
               
               
                 ifgt 
                 branch if greater than 0 
               
               
                 ifle 
                 branch if less than or equal to 0 
               
               
                 iflt 
                 branch if less than 0 
               
               
                 ifne 
                 branch if not equal to 0 
               
               
                 iinc 
                 increment local variable by constant 
               
               
                 iload 
                 load integer from local variable 
               
               
                 iload_&lt;n&gt; 
                 load integer from local variable 
               
               
                 imod 
                 peform modulo function on integers 
               
               
                 imul 
                 multiply integers 
               
               
                 ineg 
                 negate integer 
               
               
                 instanceof 
                 determine if object is of given type 
               
               
                 int2byte 
                 convert integer to signed byte 
               
               
                 int2char 
                 convert integer to char 
               
               
                 invokeinterface 
                 invoke interface method 
               
               
                 invokemethod 
                 invoke class method 
               
               
                 invokesuper 
                 invoke superclass method 
               
               
                 ior 
                 boolean OR two integers 
               
               
                 ireturn 
                 return integer from function 
               
               
                 ishl 
                 integer shift left 
               
               
                 ishr 
                 integer arithmetic shift right 
               
               
                 istore 
                 store integer into local variable vindex 
               
               
                 istore_&lt;n&gt; 
                 store integer into local variable n 
               
               
                 isub 
                 subtract integers 
               
               
                 iushr 
                 integer logical shift right 
               
               
                 ixor 
                 boolean XOR two integers 
               
               
                 jsr 
                 jump to subroutine 
               
               
                 12d 
                 convert long integer into double floating point 
               
               
                   
                 number 
               
               
                 12f 
                 convert long integer into single precision 
               
               
                   
                 floating point number 
               
               
                 12i 
                 convert long integer into integer 
               
               
                 ladd 
                 add long integers 
               
               
                 laload 
                 load long integer from array 
               
               
                 land 
                 boolean AND two long integers 
               
               
                 lastore 
                 store into long integer array 
               
               
                 lcmp 
                 compare long integers 
               
               
                 lconst_&lt;l&gt; 
                 push long integer constant 
               
               
                 ldc1 
                 push item from constant pool 
               
               
                 ldc2 
                 push item from constant pool 
               
               
                 ldc2w 
                 push long or double from constant pool 
               
               
                 ldiv 
                 divide long integers 
               
               
                 lload 
                 load long integer from local variable 
               
               
                 lload_&lt;n&gt; 
                 load long integer from local variable 
               
               
                 lmod 
                 perform modulo function on long integers 
               
               
                 lmul 
                 multiply long integers 
               
               
                 lneg 
                 Negate long integer 
               
               
                 lookupswitch 
                 Access jump table by key match and jump 
               
               
                 lor 
                 boolean OR two long integers 
               
               
                 lreturn 
                 return long integer from function 
               
               
                 lshl 
                 long integer shift left 
               
               
                 lshr 
                 long integer arithmetic shift right 
               
               
                 lstore 
                 store long integer into local variable 
               
               
                 lstore_&lt;n&gt; 
                 store long integer into local variable 
               
               
                 lsub 
                 subract long integers 
               
               
                 lushr 
                 long integer logical shift right 
               
               
                 lxor 
                 boolean XOR long integers 
               
               
                 monitorenter 
                 enter monitored region of code 
               
               
                 monitorexit 
                 exit monitored region of code 
               
               
                 new 
                 create new object 
               
               
                 newarray 
                 allocate new array 
               
               
                 newfromname 
                 create new object from name 
               
               
                 nop 
                 do nothing 
               
               
                 pop 
                 pop top stack word 
               
               
                 pop2 
                 pop top two stack words 
               
               
                 putfield 
                 set field in object 
               
               
                 putstatic 
                 set static field in class 
               
               
                 ret 
                 return from subroutine 
               
               
                 return 
                 return (void) from procedure 
               
               
                 saload 
                 load signed byte from array 
               
               
                 sastore 
                 store into signed byte array 
               
               
                 siaload 
                 load unsigned short from array 
               
               
                 siastore 
                 store into unsigned short array 
               
               
                 sipush 
                 push two byte signed integer 
               
               
                 tableswitch 
                 access jump table by index and jump 
               
               
                 verifystack 
                 verify stack empty 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 APPENDIX 1 
               
               
                 Pseudocode for OAK Bytecode Verifier 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 Receive Bytecode Program to be verified. 
               
               
                 Create Virtual Operand Stack Data Structure for storing stack status 
               
               
                 information and Virtual Local Variable Array for storing local variable 
               
               
                 data type information. 
               
               
                 Create data structure for storing Virtual Stack Snapshots. 
               
               
                 First Pass through Bytecode Program: 
               
               
                   Locate all instructions that are the targets of conditional and 
               
               
                   unconditional jumps or branches (i.e., can be entered from more than 
               
               
                   one prior instruction). 
               
               
                   Store list of such target instructions in Virtual Stack Snapshot data 
               
               
                   structure. 
               
               
                 Second Pass through Bytecode Program: 
               
               
                   Set VerificationSuccess to True 
               
               
                   Do Until Last Bytecode Instruction has been processed: 
               
               
                   { 
               
               
                   Select next bytecode instruction (in sequential order in program) 
               
               
                   If instruction is in list of target instructions 
               
               
                   { 
               
               
                   If snapshot of virtual stack for this instruction already exists 
               
               
                   { 
               
               
                   Compare current state of virtual stack with stored snapsh 
               
               
                   If snapshot does not match current virtual stack state 
               
               
                   { 
               
               
                   Print message identifying place in program that stack 
               
               
                   mismatch occurred 
               
               
                   Abort Verification 
               
               
                   Set VerificationSuccess to False 
               
               
                   Return 
               
               
                   } 
               
               
                   } 
               
               
                   Else 
               
               
                   Store snapshot of current virtual stack status 
               
               
                   } 
               
               
                   Case(Instruction Type): 
               
               
                   { 
               
               
                   Case=Instruction pops data from Operand Stack 
               
               
                   { 
               
               
                   Check for Stack Underflow 
               
               
                   If Stack has Underflowed 
               
               
                   { 
               
               
                   Print message identifying place in program that 
               
               
                   underflow occurred 
               
               
                   Abort Verification 
               
               
                   Return 
               
               
                   } 
               
               
                   Compare data type of each operand popped from stack with 
               
               
                   data type required (if any) by the bytecode instruction 
               
               
                   If type mismatch 
               
               
                   { 
               
               
                   Print message identifying place in program that data 
               
               
                   type mismatch occurred 
               
               
                   Set VerificationSuccess to False 
               
               
                   } 
               
               
                   Delete information from Virtual Stack for popped operands 
               
               
                   Update Stack Counter 
               
               
                   } 
               
               
                   Case=Instruction pushes data onto Operand Stack 
               
               
                   { 
               
               
                   Check for Stack Overflow 
               
               
                   If Stack has Overflowed 
               
               
                   { 
               
               
                   Print message identifying place in program that overfiow 
               
               
                   occurred 
               
               
                   Abort Verification 
               
               
                   Set VerificationSuccess to False 
               
               
                   Return 
               
               
                   } 
               
               
                   Add information to Virtual Stack indicating data type of data 
               
               
                   pushed onto operand stack 
               
               
                   Update Stack Counter 
               
               
                   } 
               
               
                   Case=Instruction is a forward jump or branch instruction 
               
               
                   { 
               
               
                   If snapshot of virtual stack for the target instruction already 
               
               
                   exists 
               
               
                   { 
               
               
                   Compare current state of virtual stack with stored 
               
               
                   snapshot 
               
               
                   If snapshot does not match current virtual stack state 
               
               
                   { 
               
               
                   Print message identifying place in program that 
               
               
                   stack mismatch occurred 
               
               
                   Abort Verification 
               
               
                   Set VerificationSuccess to False 
               
               
                   Return 
               
               
                   } 
               
               
                   } 
               
               
                   Else 
               
               
                   Store snapshot of current virtual stack state as snapshot 
               
               
                   for the target instruction; 
               
               
                   } 
               
               
                   Case=Instruction is an end of loop backward jump or other 
               
               
                   backward jump or branch instruction: 
               
               
                   { 
               
               
                   Compare current virtual stack state with stored snapshot for 
               
               
                   target instruction 
               
               
                   If current virtual stack state does not match stored snapshot 
               
               
                   { 
               
               
                   Print message identifying place in program that stack 
               
               
                   mismatch occurred 
               
               
                   Abort Verification 
               
               
                   Set VerificationSuccess to False 
               
               
                   Return 
               
               
                   } 
               
               
                   } 
               
               
                   Case=Instruction reads data from local variable 
               
               
                   { 
               
               
                   Compare data type of each datum read from local variable 
               
               
                   with data type required (if any) by the bytecode instruction 
               
               
                   If type mismatch 
               
               
                   { 
               
               
                   Print message identifying place in program that data 
               
               
                   type mismatch occurred 
               
               
                   Set VerificationSuccess to False 
               
               
                   } 
               
               
                   Case=Instruction stores data into a local variable 
               
               
                   { 
               
               
                   If corresponding virtual local variable alteady stores a data 
               
               
                   type value 
               
               
                   { 
               
               
                   Compare data type value stored in virtual local variable 
               
               
                   with data type of datum that would be stored in the 
               
               
                   corresponding local variable (as determined by the data 
               
               
                   type handled by the current bytecode instruction) 
               
               
                   If type mismatch 
               
               
                   { 
               
               
                   Print message identifying place in program that data 
               
               
                   type mismatch occurred 
               
               
                   Set VerificationSuccess to False 
               
               
                   } 
               
               
                   } 
               
               
                   Else 
               
               
                   Add information to Virtual Local Variable indicating data 
               
               
                   type of data that would be stored in corresponding local 
               
               
                   variable 
               
               
                   } 
               
               
                   } /* EndCase */ 
               
               
                   } /* End of Do Loop */ 
               
               
                   Return (VerificationSuccess) 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
               
                 APPENDIX 2 
               
               
                 Pseudocode for Bytecode Interpreter 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
            
               
                 Receive Specified Bytecode Program to be executed 
               
               
                 Call Bytecode Verifier to verify Specified Bytecode Program 
               
               
                 If Verification Success 
               
               
                   { 
               
               
                   Link Specified Bytecode Program to resource utility programs. 
               
               
                   Interpret and execute Specified Bytecode Program instructions without 
               
               
                   performing operand stack overflow and underflow checks and without 
               
               
                   performing data type checks on operands stored in operand stack. 
               
               
                   }