Impact of Automatic Gain Time Identification on Tree-Based Static WCET Analysis

WCET estimates obtained using static analysis methods are getting increasingly pessimistic as the complexity of hardware and software increases. The difference between the WCET of one task (estimated off-line) and its actual execution time (only known on-line) is known as gain time. Identifying gain time as soon as possible is important because it increases the number of tasks that can be accepted dynamically. While some research has already been undertaken for the identification of gain time, few work has considered the impact of gain time identification and reclaiming on static WCET analysis methods. This is the objective of this paper, in which we introduce three classes of methods for gain time identification, and discuss their impact on tree-based static WCET analysis methods. 1 Motivations for automatic gain time identification Most scheduling algorithms for hard real-time tasks assume that the WCET estimation of each task is known. A number of dynamic scheduling algorithms have also been proposed to dynamically accept soft real-time tasks when spare capacity is left by hard-real-time tasks. Spare capacity is either extra time (time known to be left by the hard real-time tasks during the design phase) or gain time (spare time appearing at run-time when hard real-time tasks execute in less than their WCET). Static WCET analysis techniques return an upper bound on the execution time of a task on a given hardware, based on its source code. Having an upper bound on all possible execution times (safety) is of prime importance in hard real-time systems to have confidence in the schedulability analysis methods. But despite the important progress made in static analysis methods, safety comes at the cost of pessimistic WCET estimations. Two sources of pessimism can be identified: (i) analysis of the execution paths, or high level analysis (when it is not known statically which path will be executed, the longest path is selected), (ii) low-level analysis (when the execution time of an instruction is not known a priori due to the use of complex processors with performance enhancing features such as caching or branch prediction, the most pessimistic execution time is selected). As the complexity of software and hardware increases, the degree of pessimism of WCET estimates also increases. In such situations, identifying and reclaiming gain time is getting increasingly important. In this paper we concentrate on the estimation of gain time, and not on its reclaiming. In our opinion, the methods for gain time identification should have the following properties: Early detection. The presence of gain time should be detected before the tasks finish their execution. The sooner the gain time is detected, the earlier new tasks can be dynamically accepted. Predictable cost. Early identifying gain time requires to monitor the progression of the tasks, which has a cost in terms of execution time. This cost has to be predictable and the designer should have means to control the cost of gain time identification. High efficiency. All gain time should be detected, should it come from the low-level or the high-level sources of pessimism of static WCET analysis. Transparency. No support (or very low support) from the designer should be required. Predictable and low memory requirements. Several techniques have been proposed for gain time identification. [3] consists in measuring the execution time of tasks between so-called gain points using specific hardware, the gain points being placed by the programmer. A software evolution of [3] is presented in [2]. In this proposal, the gain points are automatically determined, but the target language is very simple. Both [3] and [2] identify all gain times because they use measurements to monitor the tasks progress. Other methods, that only identify gain time coming from the pessimistic identification of worst-case execution paths, have been proposed in [1] and [4] (the latter tackles object-oriented hard real-time programs). The principle of these two methods is to know statically the WCET of the different paths in the program. Then, each time a path decision is taken, the gain time can be estimated, but because there are no measures of the actual execution times, the low-level analysis pessimism will not be identified. In the following, we briefly propose three classes of techniques aiming at reaching all the above-identified desirable properties and study the support that static WCET analysis should provide in order for these techniques to be implemented. 2 Three methods of gain time identification and their impact on WCET analysis All three methods use some general principles. Instrumentation code is inserted in the tasks at specific points called gain points (GP) in which the time actually consumed by the task is measured. Measurements are used to identify all sources of pessimism of WCET analysis. All three methods identify gain time on-line by subtracting the measured execution time of segments of the task code from the WCET of the same segments. The methods differ by the rules governing GP placement and the definition of a segment. Our discussion hereafter concentrates on the impact of gain time identification on tree-based WCET analysis tools. A simple example is used hereafter to illustrate the pros and cons of each method for GP placement, as well as their impact on WCET analysis. The source code of the example is presented in figure 1. Two important things can be noticed about this code: (i) the maximum number of iterations of the loop (three, as indicated in the annotation [3] in the source code) may be overestimated (the loop may execute once or twice only); (ii) the most time-consuming execution path within the loop is the “else” path, although the “then” path can be actually executed too. int i; int j; for (i=0;i<N;i++) { [3] /* Known to iterate at most 3 times */ j=3; } else { j=j+i; } } if (j==1) { Figure 1. Source code sample We can extract two data structures from this source code: the program control flow graph (left part of figure 2) and its syntax tree (right part of figure 2). The latter data structure is used in so-called tree-based WCET analysis tools to compute the WCET of a piece of code through a bottom-up traversal of its syntax tree. Figure 3 depicts for this sample program the differences that may exist between the off-line and a given on-line timeline. It shows that the actual execution time is lower than the I