8.3 Recovery at the Level of Procedures
As shown in the overview above, most of the current approaches to generating
recovery points are either located on the level of the system (one recovery point
covers the whole system) or on the level of tasks, which is the most frequently used
approach.
As shown in Sect. 8.2, the standard system model that is usually applied for
systems supporting recovery points is a fail-stop system where faults are eliminated
just by recovering the last consistent recovery point and resume processing. The
assumption in this case is that the checking schemes can detect faults either during
instruction execution or while accessing hardware devices and fail-stop.
Now, we present in this chapter our approach of generating recovery points:
Recovery points on the level of procedures. This approach tries to exploit language
features limiting the required space to save a current state of a program in every
recovery point.
Especially for the model of a fail-stop system, the fast recovery time due to the
small recovery points is tempting. If faults are masked, i.e., present but hidden in
the system, affect the program execution but are detected much later (not a fail-stop
system), recovery on the level of procedures might not be the right approach as
considerable time is required to find the last correct recovery point or no correct
recovery point at all might be present and the system must be restarted to recover.
Upon every procedure entrance, a recovery point is created which stores all
parameters, all write-accessed variables the stack and the base pointer, and the
current program counter.
This allows minimizing the footprint of each recovery point. The compiler
analyzes the program code and emits additional code in the procedure preamble to
create the recovery point. Keep in mind that temporary variables on the stack do not
need to be included in the recovery frame. The same is valid for the processor
registers, assuming parameter passing via stack and not registers. The actual storing
mechanism needs runtime support, especially if it is stored on external stable
storage.
A recovery block entry usually has the format shown in Table 8.1.
In the field address, the physical address of the source variable is stored. The
field size contains the size of the variable in number of bytes followed by the data
itself. For fixed-size variables such as basic types or statically allocated arrays, the
data size can be derived at compile time.
For storing these, one could actually omit the field size and store the data
immediately after the address. However, it is not possible to derive the size of
objects, or records at compile time, as also derived elements could be passed as an
Table 8.1 Recovery block
frame
Address
Size
Data
4 bytes
4 bytes
n bytes
…
…
…
122
8 Recovery Preparation
As shown in the overview above, most of the current approaches to generating
recovery points are either located on the level of the system (one recovery point
covers the whole system) or on the level of tasks, which is the most frequently used
approach.
As shown in Sect. 8.2, the standard system model that is usually applied for
systems supporting recovery points is a fail-stop system where faults are eliminated
just by recovering the last consistent recovery point and resume processing. The
assumption in this case is that the checking schemes can detect faults either during
instruction execution or while accessing hardware devices and fail-stop.
Now, we present in this chapter our approach of generating recovery points:
Recovery points on the level of procedures. This approach tries to exploit language
features limiting the required space to save a current state of a program in every
recovery point.
Especially for the model of a fail-stop system, the fast recovery time due to the
small recovery points is tempting. If faults are masked, i.e., present but hidden in
the system, affect the program execution but are detected much later (not a fail-stop
system), recovery on the level of procedures might not be the right approach as
considerable time is required to find the last correct recovery point or no correct
recovery point at all might be present and the system must be restarted to recover.
Upon every procedure entrance, a recovery point is created which stores all
parameters, all write-accessed variables the stack and the base pointer, and the
current program counter.
This allows minimizing the footprint of each recovery point. The compiler
analyzes the program code and emits additional code in the procedure preamble to
create the recovery point. Keep in mind that temporary variables on the stack do not
need to be included in the recovery frame. The same is valid for the processor
registers, assuming parameter passing via stack and not registers. The actual storing
mechanism needs runtime support, especially if it is stored on external stable
storage.
A recovery block entry usually has the format shown in Table 8.1.
In the field address, the physical address of the source variable is stored. The
field size contains the size of the variable in number of bytes followed by the data
itself. For fixed-size variables such as basic types or statically allocated arrays, the
data size can be derived at compile time.
For storing these, one could actually omit the field size and store the data
immediately after the address. However, it is not possible to derive the size of
objects, or records at compile time, as also derived elements could be passed as an
Table 8.1 Recovery block
frame
Address
Size
Data
4 bytes
4 bytes
n bytes
…
…
…
122
8 Recovery Preparation