modified memory addresses could result in accessing memory outside of the
assigned memory address space. Various variants exist of handling these faults:
1. SW(T, S): Control flow checking by software signatures, introduced in [15] and
elaborated in [16]: The compiler introduces branch checks by using signatures
to validate the control flow. Although many faults are found by using this
technique, the overhead in size and time is significant (size: 25–60%, time: 16–
70%). Note that this approach does not rely on specialized hardware and constitutes a pure software solution. Variants do also exist that involve an additional
hardware processor to calculate these signatures. Alternatively, duplicated
instructions or double program execution SW(2T) with output comparison [17–
19] could be used, also which high execution overhead of 40–200%
2. SW(T), SW(T, S): The use of multiple independent runs of the same or different
programs with output comparison, sequential or concurrent [20–22].
3. SW(T, I): Use hardware/software fault detection (checkpoints, syndrome)
together with recovery points to perform recovery.
In our context, a complex virtual memory addressing scheme is not desirable.
We therefore believe that the adaption of the language could help to support an
efficient implementation of recovery points.
In the next sections, the requirements to fault tolerance for each software
component of the runtime system are shown.
8.2 Overview of Existing Backward Recovery Techniques
Two different types of fundamentally recovery are possible: backward recovery and
forward recovery.
In the former case, the system uses previously stored system states to rollback
program execution and restore a consistent fault-free software state in case of a
failure.
In the latter case, the system is recovered by finding a new possible, consistent
state without using previously stored information. Forward recovery is always
application-dependent and needs, therefore, additional overheads. Backward recovery, in contrast, can be applied in both ways: application-dependent
semi-transparent and application transparent:
Semi-transparent The application programmer is responsible for storing the
application state in a consistent state for later rollback [23]. More recently, a
semi-automatic recovery process called Microreboot [24] was presented, which
does not require the application to create recovery points, but requires a specific
software architecture with stable storage such as a database.
Application transparent The programmer is not involved in the process of creating
recovery points, i.e., application need not be modified. In this case, the compiler
114
8 Recovery Preparation
assigned memory address space. Various variants exist of handling these faults:
1. SW(T, S): Control flow checking by software signatures, introduced in [15] and
elaborated in [16]: The compiler introduces branch checks by using signatures
to validate the control flow. Although many faults are found by using this
technique, the overhead in size and time is significant (size: 25–60%, time: 16–
70%). Note that this approach does not rely on specialized hardware and constitutes a pure software solution. Variants do also exist that involve an additional
hardware processor to calculate these signatures. Alternatively, duplicated
instructions or double program execution SW(2T) with output comparison [17–
19] could be used, also which high execution overhead of 40–200%
2. SW(T), SW(T, S): The use of multiple independent runs of the same or different
programs with output comparison, sequential or concurrent [20–22].
3. SW(T, I): Use hardware/software fault detection (checkpoints, syndrome)
together with recovery points to perform recovery.
In our context, a complex virtual memory addressing scheme is not desirable.
We therefore believe that the adaption of the language could help to support an
efficient implementation of recovery points.
In the next sections, the requirements to fault tolerance for each software
component of the runtime system are shown.
8.2 Overview of Existing Backward Recovery Techniques
Two different types of fundamentally recovery are possible: backward recovery and
forward recovery.
In the former case, the system uses previously stored system states to rollback
program execution and restore a consistent fault-free software state in case of a
failure.
In the latter case, the system is recovered by finding a new possible, consistent
state without using previously stored information. Forward recovery is always
application-dependent and needs, therefore, additional overheads. Backward recovery, in contrast, can be applied in both ways: application-dependent
semi-transparent and application transparent:
Semi-transparent The application programmer is responsible for storing the
application state in a consistent state for later rollback [23]. More recently, a
semi-automatic recovery process called Microreboot [24] was presented, which
does not require the application to create recovery points, but requires a specific
software architecture with stable storage such as a database.
Application transparent The programmer is not involved in the process of creating
recovery points, i.e., application need not be modified. In this case, the compiler
114
8 Recovery Preparation