Limitations and Future Work

3.4.6 Mixed execution.

To apply mixed execution on AODV, we needed to determine which parts of the AODV code to execute on the host JVM. We first marked to run on mixed mode all methods of the data structures that AODV uses to represent protocol data. This includes routing tables and packet queues. Then, we profiled the model checker execution to find that it spends a lot of execution time in the methods from the library classPort. This class handles the sending and receiving of packets between network nodes [Tya02], so we also marked those methods for execution in mixed mode.

Figure 3.4 shows the improvements obtained with mixed execution on AODV. We tabulate, for a range of number of nodes and length of the event path, given by column N, the overall state-space exploration time and the method execution time. Mixed execution improves the overall exploration time from 1.14x to 1.41x (with median 1.23x), and the method execution time from 3.27x to 4.35x (with median 3.54x).

meth-ods are atomic (deterministic) so that the model checker will not miss any behavior by imposing a sequential execution order. A very conservative approach to automate this check in mixed execu-tion is to track for each thread the set of shared variables it can access. The model checker would then identify as potentially non-deterministic an execution of a method that can access data that another thread can read or write. We leave as future work to investigate approaches for identifying atomic blocks to speed up execution.

Improved translation from JVM to JPF state. The current implementation of Mixed execution writes back to the JPF state all fields that have been read during the execution of a method in mixed mode. We can improve the translation from JVM to JPF representation to avoid writing fields which are not modified in the execution. It is possible, for example, to associate to each field a dirty flag that indicates whether or not execution wrote to that field, or associate a dirty flag to each object.

Improved translations with memoization. Using immutable data is a common design pattern. For example, most classes in thejava.langpackage follow this pattern: it is not possible to mutate the state of a String or an Integer object. Mixed execution can also be improved by identifying types that are strictly functional or functional with respect to the environments a test driver exercises. The model checker can translate to native representation the objects of these types once and for all (modulo garbage collection). The native state could keep references to these objects in native representation to avoid repeated translations of state.

Support static fields. The current implementation of mixed execution does not consider static fields, i.e., it does not update the model checker’s special state representation when code that executes in mixed mode writes to static fields. The experiments did not exercise such cases and thus static fields was not an issue in our evaluation. In principle, we can instrument all writes to non-final static fields to record modification. Mixed execution could therefore identify and mutate the parts of the state of the model checker that corresponds to static fields that have been modified during mixed execution.

Speeding up native method calls. The current implementation of Mixed execution uses Java reflection [SM03] to invoke operations on the subject under test. This invocation is slow.

The implementation can avoid the cost of reflective calls by instrumenting specialized operations

mc

mc

operating system regular JVM pgm

regular JVM

pgm

data

data

data

mc

Figure 3.8: Model checkers with different environments for execution. The right arrows denote progressive program transformations. The leftmost model checker executes program transitions on the program mc, the second on the regular JVM, and the third directly on the host machine.

on each subject or even creating specialized bytecode instructions, in the case of JPF, for each method or class that runs in mixed mode.

Engineering a model checker for fast execution. We want to investigate different designs in the construction of a program model checker. In particular, we want to investigate designs of model checkers that can lead to efficient execution of transitions. Figure 3.8 illustrates possible alternatives for the construction of a model checker.

In the first alternative, the model checker is a Java program that runs on top of a JVM. The program to model check,pgm, is passed as data to the programmc that corresponds to the model checker. This results in slow execution: the bytecodes of the subject program executes in a virtual machine that runs on top of a regular virtual machine.

The second alternative specializes the model checker to one specific program. This avoids interpretation of the transitions of pgm in mc. Automatic transformation from the first to the second design requires a compiler, in essence a partial evaluator [JGS93], that takes the model checker mc as input and produces a new model checker specialized to the new program. More precisely, the compiler translates the program mc : pgm×datapgm → output into the program mcpgm : datapgm → output. The input data refers to the parameters for the search and output refers to a description of the program paths that the model checker explores. Another approach to perform this transformation is to modify the input program to become model checkable. For example, instrumenting field writes to allow restoration of state and introducing non-deterministic

choices wherever is necessary.

The last design alternative illustrates a model checker that runs on top of the host machine.

The program mcpgm, combining model checker and input program, is written in C, for instance.

Transformation of the second to the third design requires translation from Java to, say, C [jik].

JPF, for example, follows the first alternative. The JPF’s JVM runs on top of a regular virtual machine, but the program to model check runs on top of JPF’s virtual machine. BOX follows the second alternative. BOX provides a library for storing, partially restoring state, and re-executing the program. The user needs to write a test driver and instrument the program specially to allow state restoration (see Section 4.3.2 for details). Verisoft [God97] and CMC [MPC⁺02] follow the third design. The model checker runs directly on top of the host machine.

We want to investigate how the alternatives above impact efficiency in model checkers that operate on special state representations and on top of a regular JVM, such as JPF.