Abstract:
A tool is provided for modifying the code of a multi-threaded computer program undergoing testing. The program executes in an environment that has a governing memory model. It is assumed that there is a global heap and a thread-local heap, which are synchronized from time to time. The modifications are of two types: (1) code instructions are reordered while remaining in compliance with the memory model; and (2) thread-local variables are added to functions, together with inserted heap synchronizing instructions. The modified programs are then used by a test generator to prepare test cases for execution. The modifications have the effect of changing the interleavings that occur among different threads, and increase the likelihood of exposing flaws that may become evident under different memory models.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of the Invention  
         [0002]     This invention relates to testing computer software. More particularly, this invention relates to testing software, which runs concurrently as multiple processes or threads, or on distributed processors.  
         [0003]     2. Description of the Related Art  
         [0004]     The main problem in testing a concurrent computer program, which executes as a plurality of threads or operates on a plurality of distributed platforms, is nondeterminism: two executions of such a program may yield different results. Most of the work in the field of concurrent testing has been focused on detecting race conditions. However, race conditions have a low probability of manifesting themselves, and even when they do, it is not always an indication of a fault. In any case, identifying race conditions is insufficient. It is possible that a program without races contains concurrent bugs, e.g., bugs due to incorrect usage of message-based synchronization.  
         [0005]     Another approach to testing software is disclosed in the documents O. Edelstein, E. Farchi, Y. Nir, G. Ratsaby, and S. Ur.,  Multithreaded Java Program Test Generation, IBM Systems Journal,  41(1):111-125, 2002, and S. D. Stoller,  Model - checking Multi - threaded Distributed Java Programs,  in  Proceedings of the  7 th International SPIN Workshop on Model Checking of Software,  pages 224-244, New York, 2000, Springer Verlag, which are herein incorporated by reference. The problem of generating different interleavings for the purpose of revealing concurrent faults was approached by seeding the program with conditional sleep statements at shared memory access and synchronization events. At run time, random, biased random, or coverage-based decisions were taken as to whether to execute seeded primitives. However, neither race detection nor the seeding approach helps detect bugs related to multi-layer memory models if the tests are executed on one-layer memory implementations.  
         [0006]     Furthermore, the space of possible temporal orders of instruction executions by different threads that may be scheduled by a runtime environment, known as interleavings, is an exponential function of the program size. In the typical testing environment, little coverage of the space of possible interleaving is achieved. The term “coverage” concerns checking and showing that testing has been thorough. Coverage is any metric of completeness with respect to a test selection criterion for the program-under-test. The definition of coverage events is usually specific to a program-under-test, and constitutes a major part in the definition of the testing plan of the program.  
         [0007]     The problem of testing multi-threaded programs is further compounded by the fact that tests that reveal a concurrent fault in the field or during stress testing are usually long and run under variable environmental conditions. For example, on a given machine, tasks launched asynchronously by the operating system may alter the machine&#39;s environment sufficiently to affect the results of two different executions of the same multi-threaded program. As a result, such tests are not necessarily repeatable. When a fault is detected, much effort must be invested in recreating the conditions under which it occurred.  
         [0008]     In particular, the semantics of different versions of the Java™ two-layer memory model are a constant source of programmer misunderstandings and concurrent bugs. The Java memory model is described in the document,  The Java Language Specification,  James Gosling, Bill Joy, Guy Steele., Addison Wesley, 1996, and more recently in the document, JSR-133:  Java Memory Model and Thread Specification,  available at “http://jcp.org/aboutJava/communityprocess/final/jsr133/index.html”. The memory model addresses the issue of heap synchronization. For various reasons, such as promoting efficient usage of multiprocessor machines, Java defines a two-layer model of the heap. Each thread operates on its own version of the heap, which in turn communicates with a global upper heap layer. The memory model defines the rules for this communication: when a thread executes certain operations, the executing environment must write the global heap onto the local one or vice versa. Another issue addressed by the memory model is instruction reordering. Many compiler optimizations are dependent on the ability of the compiler to reorder or duplicate instructions, issue prefetching requests, etc. However, a seemingly innocuous permutation at the thread level may change the program behavior because of interaction with other threads. Again, it is the responsibility of the memory model to define which permutations are allowed and which are not. The standard proposed in the above-noted JSR-133 model permits different kinds of heap synchronization and instruction reordering rules than its predecessor. Thus, programs that worked correctly under the old Java memory model may malfunction when run under JSR-133.  
         [0009]     It is anticipated that the problems outlined above will become even more acute as new computer chips are equipped with two or more processors, and runtime implementations make use of the two-layer memory model.  
       SUMMARY OF THE INVENTION  
       [0010]     According to a disclosed embodiment of the invention, a tool is provided for modifying the code of a multi-threaded computer program undergoing testing. The program executes in an environment that has a governing memory model. It is assumed that there is a global heap and a thread-local heap, which are synchronized from time to time. The code modifications are typically class modifications and are of two types: (1) reordered code instructions that remain in compliance with the memory model; and (2) addition of thread-local variables to functions, together with insertion of synchronizing instructions that force synchronization of the global and thread-local heaps at selected points in the functions. The modified programs are then executed for testing purposes. These modifications have the effect of changing the interleavings that occur among different threads, and increase the likelihood of exposing program flaws that may become evident under different memory models.  
         [0011]     The invention provides a method of testing a concurrently operating original computer program that operates under a memory model, which is carried out by reordering a plurality of instructions of the program while remaining in compliance with the memory model to define a modified program, and generating tests using the modified program for execution in order to verify correct operation of the original computer program.  
         [0012]     In one aspect of the method, reordering is done by exchanging two of the instructions.  
         [0013]     In another aspect of the method, the program has classes, and reordering includes modifying one of the classes.  
         [0014]     According to one aspect of the method, the memory model is a one-layer memory model.  
         [0015]     According to another aspect of the method, the memory model is a two-layer memory model.  
         [0016]     The invention provides a computer software product, including a computer-readable medium in which first computer program instructions are stored, which instructions, when read by a computer, cause the computer to perform a method for testing a concurrently operating second computer program that operates under a memory model, which is carried out by reordering a plurality of instructions of the second computer program while remaining in compliance with the memory model to define a modified second computer program, and generating tests using the modified second computer program for execution in order to verify correct operation of the original second computer program.  
         [0017]     The invention provides a system for testing a concurrently operating original computer program that operates under a memory model, including a test generator operative to reorder a plurality of instructions of the program, while remaining in compliance with the memory model to define a modified program. The test generator is adapted to prepare a suite of tests using the modified program, and an execution engine for executing the tests in order to verify correct operation of the original computer program.  
         [0018]     The invention provides a method of testing a concurrently operating original computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, which is carried out by adding a first variable to a function of the program. The first variable is thread-local, and is stored in the thread-local heap. The first variable corresponds to a second variable that is stored in the global heap. The method is further carried out by inserting synchronizing instructions at selected points in the function for synchronizing the global heap and the thread-local heap so as to equate a value of the first variable and a value of the second variable. The method is further carried out by preparing a suite of tests for execution using a modified program that includes the first variable and the synchronizing instructions in order to verify correct operation of the original computer program.  
         [0019]     The invention provides a computer software product, including a computer-readable medium in which computer program instructions are stored, which instructions, when read by a computer, cause the computer to perform a method of testing a concurrently operating second computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, which is carried out by adding a first variable to a function of the second computer program. The first variable is thread-local, is stored in the thread-local heap, and corresponds to a second variable that is stored in the global heap. The method is further carried out by inserting synchronizing instructions at selected points in the function for synchronizing the global heap and the thread-local heap so as to equate a value of the first variable and a value of the second variable. The method is further carried out by preparing a suite of tests for execution using a modified second computer program that includes the first variable and the synchronizing instructions in order to verify correct operation of the original second computer program.  
         [0020]     The invention provides a system for testing a concurrently operating original computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, including a test generator operative to add a first variable to a function of the program, the first variable being thread-local, and being stored in the thread-local heap. The first variable corresponds to a second variable that is stored in the global heap. The test generator is operative at selected points in the function to insert synchronizing instructions for synchronizing the global heap and the thread-local heap so as to equate a value of the first variable and a value of the second variable, and to prepare a suite of tests using a modified program that includes the first variable and the synchronizing instructions. The system includes an execution engine for executing the tests in order to verify correct operation of the original computer program.  
         [0021]     The invention provides a method of testing a concurrently operating original computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, which is carried out by adding a first variable to a function of the original computer program, the first variable being thread-local and stored in the thread-local heap. The first variable corresponds to a second variable that is stored in the global heap. The method is further carried out by substituting a reference to the first variable for a reference to the second variable in the function, inserting a synchronizing instruction in the function that is subsequent to the reference to the first variable so as to equate the first variable and the second variable, and preparing tests for execution using a modified program that includes the first variable and the synchronizing instruction in order to verify correct operation of the original computer program.  
         [0022]     The invention provides a computer software product, including a computer-readable medium in which first computer program instructions are stored, which instructions, when read by a computer, cause the computer to perform a method for testing a concurrently operating second computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, which is carried out by adding a first variable to a function of the second computer program, the first variable being thread-local and stored in the thread-local heap. The first variable corresponds to a second variable that is stored in the global heap. The method is further carried out by substituting a reference to the first variable for a reference to the second variable in the function, inserting a synchronizing instruction in the function that is subsequent to the reference to the first variable so as to equate the first variable and the second variable, and preparing tests for execution using a modified program that includes the first variable and the synchronizing instruction in order to verify correct operation of the second computer program.  
         [0023]     The invention provides a system for testing a concurrently operating original computer program that operates as a plurality of threads under a memory model that includes a global heap and a thread-local heap, including a test generator operative to produce a modified program by adding a first variable to a function of the original computer program. The first variable is thread-local and is stored in the thread-local heap. The first variable corresponds to a second variable that is stored in the global heap. The test generator is operative for substituting a reference to the first variable for a reference to the second variable in the function, and inserting a synchronizing instruction in the function that is subsequent to the reference to the first variable so as to equate a value of the first variable and a value of the second variable, and preparing tests using the modified program. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0024]     For a better understanding of the present invention, reference is made to the detailed description of the invention, by way of example, which is to be read in conjunction with the following drawings, wherein like elements are given like reference numerals, and wherein:  
         [0025]      FIG. 1  is a block diagram of a testing system for concurrent computer programs that is operative in accordance with a disclosed embodiment of the invention; and  
         [0026]      FIG. 2  is a flow chart illustrating a method of functional testing of a multithreaded computer program by code reordering in accordance with a disclosed embodiment of the invention.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0027]     In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art, however, that the present invention may be practiced without these specific details. In other instances well-known circuits, control logic, and the details of computer program instructions for conventional algorithms and processes have not been shown in detail in order not to obscure the present invention unnecessarily.  
         [0028]     Software programming code, which embodies aspects of the present invention, is typically maintained in permanent storage, such as a computer readable medium. In a client-server environment, such software programming code may be stored on a client or a server. The software programming code may be embodied on any of a variety of known media for use with a data processing system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, compact discs (CD&#39;s), digital video discs (DVD&#39;s), and computer instruction signals embodied in a transmission medium with or without a carrier wave upon which the signals are modulated. For example, the transmission medium may include a communications network, such as the Internet. In addition, while the invention may be embodied in computer software, the functions necessary to implement the invention may alternatively be embodied in part or in whole using hardware components such as application-specific integrated circuits or other hardware, or some combination of hardware components and software.  
         [0029]     The embodiments herein are disclosed in part with reference to particular memory models, for example variants of the above-noted Java memory mode. However, the invention is not limited to such examples, and may be practiced with many different memory models.  
         [0000]     System Overview.  
         [0030]     Turning now to the drawings, reference is initially made to  FIG. 1 , which is a block diagram of a testing system for concurrent or distributed computer programs that is operative in accordance with a disclosed embodiment of the invention. A generic testing system  10 , used for testing concurrent software, such as multithreaded software, has several basic interacting components. The system  10  is merely exemplary; the principles of the invention can be applied to many different testing systems.  
         [0031]     The testing system  10  enables the creation of tests that have various degrees of randomness. The testing system  10  typically contains provisions for introducing random modifications or provisions for randomization of the tests or biasing them toward conditions of interest, for example bug patterns as described in the document  Concurrent Bug Patterns and How to Test Them,  Eitan Farchi et al., in Proceedings IPDPS 2003:286, which is herein incorporated by reference.  
         [0032]     Testing knowledge is stored in the system  10 . This includes a memory model, which can be a one-layer or two-layer memory model, or an even more complex memory model. This information may be stored in a database  15 , and may include testing constraints, coverage criteria, bug patterns, and configuration information for a generic test generator engine  22 .  
         [0033]     The test generator engine  22  has a user input  20 , which influences the test generator engine  22 . The influence of the input  20  includes, for example, biasing hints. The test generator engine  22  can be modified using techniques known to those skilled in the art in order to generate reordered code in accordance with the principles of the invention, as explained in further detail hereinbelow. In some applications, the test generator engine  22  may be realized as a plug-in. Alternatively, it can be a standalone tool. The tool described in the above-noted document,  Multithreaded Java Program Test Generation,  is suitable for the test generator engine  22 .  
         [0034]     The test generator engine  22  may receive some generic knowledge of the program specification, and can exploit this knowledge so as to generate sequences of instructions to form a suite of tests  30  for execution. The tests can be modifications of the program code or its running environment. Typically, the tests  30  include listings of multiple threads or processes that are executed concurrently by an execution engine  12  on an implementation of a system suitable for the program under test, and which have biased or randomly selected interleavings. The system can be a hardware system, a complex software implemented system, or a hardware simulator. Indeed, the computer program being tested may itself be a simulation program.  
         [0035]     Execution of the tests  30  produces a response  34  from the system. The response  34  is submitted to a validation engine  36 , which has knowledge of the expected response, validates the response  34 , and produces validation results  38 . The validation engine  36  may analyze the coverage of the tests  30 . Typically, individual tests may be re-executed several times, in order to produce different interleavings.  
         [0036]     As the space of possible interleavings of a multithreaded system is exponential, it is necessary to bias interleaving generation based on testing knowledge. Prior attempts have focused on biasing interleaving generation based on bug patterns, anomalies, and coverage criterion. The present invention focuses on problems relating to the governing memory model. By creating tests that are likely to expose concurrent program flaws that relate to the memory model, it is possible to produce legal interleavings that could not be realized heretofore.  
         [0037]     As explained above, the governing memory model specifies the way in which compiler optimizations can reorder code and how the runtime environment must manage data transfer from the global heap. A compiler uses this information to generate faster, more efficient programs. The same information is exploited according to the invention for the purposes of test generation. The approach is as follows: before the program execution, and additionally or alternatively at class load time, and additionally or alternatively at points during the program execution, the class code is changed by a testing tool, which itself can be a computer program. The code can thus be modified substantially with or without human intervention. The modified code continues to meet requirements of the memory model, but some operations are reordered. Additionally or alternatively, data transfers to and from the heap are modified so as to create the effect of delay.  
         [0038]     In the case of Java, the above-mentioned modifications can be performed by a tool that is not part of the Java virtual machine (JVM), but plugs into the JVM. This can be accomplished, using the Java Platform Profiling Architecture, as described in the document JSR-163, available at “http://jcp.org/aboutJava/communityprocess/final/jsr163/index.html”. Alternatively, the Java just-in-time compiler (JIT), which is a part of the JVM, can be used. The output of the tool modifies the code that is executed by the execution engine  12  and the tests that are produced by the test generator engine  22 .  
         [0000]     Code Transformations and Reordering.  
         [0039]     The tool that is used according to the present invention introduces changes in the code of methods defined by a class, either statically (before execution), during class loading or reloading, or during class compilation or recompilation. Reloading or recompilation may be caused by the normal functioning of the JVM or by the tool itself. Specifically, the tool performs both code motion transformations and transformations that have the effect of delaying heap transfers. Such transformations must obey the restrictions imposed by the memory model; subject to this, they can be selected or based on coverage or heuristic considerations.  
         [0040]     For example, according to the memory model described in the document  The Java™ Virtual Machine Specification Second Edition,  Lindholm, Tim, and Yellin Frank, available at the URL “http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html”, which is herein incorporated by reference: 
        (1) Within a thread, all events appear to be totally ordered.     (2) For every heap variable, all events accessing the variable appear to be totally ordered.     (3) For every lock, all events accessing this lock appear to be totally ordered.     (4) At each synchronized block entry, variable values from the global heap are read into the thread-local heap.     (5) At each synchronized block exit, variable values from the thread-local heap are written into the global heap.        
 
         [0046]     To facilitate an understanding of code reordering, consider the example of Listing 1.  
                                                       Listing 1                                    /* A, B are heap variables initialized to 0.            * r1, r2 are thread-local (e.g., stack-allocated)            * variables            */                T1:   T2:           r1 = A   r2 = B           B = 1   A = 2           print r1   print r2                      
 
         [0047]     The possible outputs of this program if the instruction order is preserved are the pairs 0 0, 0 1, 1 0, 0 2, 2 0, but not the pairs 1 2 or 2 1. However, the memory model allows one to swap the order of the first two instructions in the thread T 1 . The first rule of the memory model is not violated since this change is transparent for all the events in the thread T 1 . The resulting code is shown in Listing 2.  
                                                       Listing 2                                    /* A, B are heap variables initialized to 0.            * r1, r2 are thread-local (e.g., stack-allocated)            * variables            */                T1:   T2:           B = 1   r2 = B           r1 = A   A = 2           print r1   print r2                      
 
         [0048]     One of the possible interleavings for this code is shown in Listing 3.  
                                             Listing 3                                    B = 1   //T1           r2 = B   //T2           A = 2   //T2           r1 = A   //T1           Print r1   //T1           Print r2   //T2                      
 
         [0049]     Thus, the possible outputs now include the pairs 1 2 and 2 1. Without recourse to the memory model, it would not be possible to produce this test using known techniques.  
         [0050]     Reference is now made to  FIG. 2 , which is a flow chart illustrating a method of functional testing of a multi-threaded computer program by code reordering in accordance with a disclosed embodiment of the invention. At initial step  40 , a method or code sequence within a program under test is selected for code reordering and transformations. It is assumed that a memory model is in force, which limits the reordering possibilities.  
         [0051]     Next, at step  42  all or some of the shared variables accessed within the method or code sequence that was selected at initial step  40  are duplicated, for example, by the means of thread-local variables or new local variables. Initialization and manipulation of these duplicate variables depends on the rules laid down by the memory model. For example, in the current versions of the Java two-layer model, at least the transformations shown in the following steps are possible.  
         [0052]     Next, at step  44  instructions are replaced. For example, if x is a non-volatile variable, an instruction of the form t=x, where t is local, can be replaced with lcl_x=x; t=lcl_x, where lcl_x is a local or thread-local variable.  
         [0053]     Next, at step  46 , the first instruction of the pair that was replaced in step  44  can be moved to an earlier stage of the program, but not earlier than the nearest point where variable values from the global heap are read into the thread-local heap according to the memory model or x is read by a different instruction.  
         [0054]     Similar transformations for step  44  and step  46  are possible when reading non-volatile fields. If x is a non-volatile variable, or un is a non-volatile field, an instruction of the form x=t or p.x=t, where t is local, can be replaced with lcl_x=t; x=lcl_x or p.x=lcl_x, where lcl_x is a local or thread-local variable. The last instruction of the pair can be moved to a later stage of the program but not later than the nearest point where variable values from the thread-local heap are written onto the global heap according to the memory model or x or p.x is written by a different instruction.  
         [0055]     Instruction reordering as described above is performed using one of the well-known instruction scheduling algorithms under the restrictions imposed by the memory model. The reordering algorithm may do rescheduling randomly, pseudo-randomly, or may be guided by pattern-based heuristics. Fore example, relevant techniques include swapping instruction order, speculatively promoting instructions or demoting instructions.  
         [0056]     Control now proceeds to final step  48 . The method or code sequence as transformed may now be executed. Method execution is likely to result in a different interleaving than would be seen without the rearrangement.  
       EXAMPLE  
       [0057]     There is a well-known bug pattern related to two-layer memory model, namely, the double-checked locking bug, an example of which is given in Listing 4.  
                                                                                                                                             Listing 4                                    class Foo{                public int x;           public Foo(int _x){x=_x;}                }           class Bar{                private static Foo foo = null;           public static void printFoo( ){                if (foo == null) {                synchronized(this){                if (foo == null) {foo = new Foo(17);}                }//synchronized                }           System.out.println(foo.x);                }                }                      
 
         [0058]     The problem arises if the thread performs the first test for nullity, which is non-synchronized, and finds that the variable foo is non-null. In this case, the synchronized block is never entered. If the code executes on a JVM with a one-layer memory implementation, the method printFoo( ) will always print 17. However, on a machine with two-layer memory, the following scenario is possible:  
         [0059]     Thread T 1  executes Bar.printFoo( ), initializing Bar.foo (and Bar.foo.x). Note that at the exit from the synchronized blocks the updated variable values are copied from T 1 &#39;s copy of the heap to the global heap  
         [0060]     Thread T 2  executes Bar.printFoo( ). Upon the method entry, T 2 &#39;s local version of the heap has the updated value of Bar.foo, but not Bar.foo.x. Therefore, the synchronized section is not entered, the global heap is not copied fully to T 2 &#39;s heap, and the method prints out 0.  
         [0061]     The conventional techniques noted above cannot reproduce this bug on a JVM with a one-layer memory implementation. The tool according to the invention, however, could store the values of the accessed variables, and modify the code as shown in Listing 5:  
                                                                                                                                                                                     Listing 5                                    class Foo{                public int x;           public Foo(int _x){x=_x;}                }           class Bar{                private static Foo foo = null;           public static void printFoo( ){                int lcl_x;           if (foo == null) {                lcl_x = 0;           synchronized(this){                if (foo == null) {                foo = new Foo(17);           lcl_x = foo.x;                }                }//synchronized                }else{                lcl_x = foo.x;                }           System.out.println(lcl_x);                }                }                      
 
         [0062]     The system would first replace, as described above, the direct access to foo.x (println(foo.x)) with a two-staged access: lcl_x=foo.x; println(lcl_x). Then the former instruction is promoted. It is replicated in the process, since the basic block where it is originally defined has several predecessors.  
         [0063]     Now, a test execution engine could print out the value 0 on a JVM with a one-layer memory implementation. Use of data transfer delay, with or without code reordering, has the effect of varying the interval between the assignment of a shared variable by a first thread and its use by a second thread. Indeed, elaboration of the technique will occur to those skilled in the art, for example by assignments of a shared variable by different threads, and access of the variable by still other threads at different times. The technique thus permits many different interleavings to be evaluated by a testing system.  
         [0064]     It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.