This project is placed in the context of Ptolemy II, a tool for heterogeneous modeling and execution. In Ptolemy II, a model is constructed with blocks, which are either directors or actors. A director is a unique entity in a model (or a sub-model residing in a larger model) that decides how it should work. It decides which domain the model is in (e.g., continuous time, discrete time, synchronous data flow, etc). If scheduling, buffering, or other mechanisms are required, the director also has implementation for them. Actors are building blocks of a model (or sub-model). Each atomic actor implements a basic computation with the input data, and possible produces some output data. Atomic actors may be grouped as composite actors. Actors are liked with each other with channels between an output ports and input ports.

Unlike some other modeling environments, directors and atomic actors in Ptolemy II are Java classes written according to some conventions. Those convensions are not important to our discussion. In this project, I treat those directors and actors as standard Java programs.

The problem to be solved in this project arises from distributed execution of Ptolemy II models. For a model to run distributedly, different components in it are placed on different computers connected with a network. As it runs, the model maintains its logic time, which defines the order of events occuring in the model. For performance reason, a component is allowed to advance its local logic time as far as no inconsistency is seen. If two components never exchanges messages, their local logic time can be substantially different.

Now support two components, which have not heard from each other for a very long time, now exchange a message. The message is received by the faster (meaning that its logic time is more in advance) component, but the message is tagged with a sending time less than the current time of the receiver. At this point, the receiver notices an inconsistency, and it must roll back. Because of the effect of that message, the computation on the receiver after the message time may be different, and the local state of the receiver should be re-computed.

Several challenges that this project must face includes:

There many existing software fault tolerance methods. A special kind, which is not fully studied, is addressed in this projects. It makes the following assumptions:

The basic part of this refactoring to transform each assignment to state variables (once they are detected) into a backup function. The backup function first records the previous state of the affected variable, and then assign a new value to it. E.g., assume the following assignment to state variable a:

a = 1;

It can be refactored as:

$ASSIGN$a(1);

The function $ASSIGN$a is a new function as follows:

private int $ASSIGN$a(int newValue) {
    if (a checkpoint is created) and
       (a is not backed up since the creation of the checkpoint)
        record the current value of a;
    return a = newValue;
}

In this way, assuming that every assignment to state variables (remind that they must be private) in the current class are precisely captured and transformed, they are always backed up before change.

One may use arrays as state variable, in which case the above solution does not quite work. In the following example, the first assignment is correctly refactored, but not the second or third:

a = new char[1][];
a[0] = new char[1];
a[0][0] = 'A';

As an improved solution, the refactoring should take arrays into account and generate different functions for different numbers of indices. This would correctly refactor the above example as follows:

$ASSIGN$a(new char[1][]);
$ASSIGN$a(0, new char[1]);
$ASSIGN$a(0, 0, 'A');

The following three functions are generated:

private char[][] $ASSIGN$a(char[][] newValue) {
    ...
}
private char[] $ASSIGN$a(int index0, char[] newValue) {
    ...
}
private char $ASSIGN$a(int index0, int index1, char newValue) {
    ...
}

Another difficulty arising from arrays is assigning them to local variables or passing them as parameters to functions. In such cases, unless context-sensitive analysis is used, we have to copy the whole array as serialization would do. Considier the following example, where a is a state variable with array type:

int[] iArray = a;
iArray[0] = 0;

The approach discussed above cannot detect this change in element 0. It is necessary to back up a whenever it is assigned to a variable (or used as an actual parameter).

Collection types, such as hash tables and sets, also cause problem. The solution is to subclass every collection type, and in each function that changes its element(s), the change is recorded before it takes effect.