Removing useless variables in cost analysis of Java bytecode

Abstract

Automatic cost analysis has interesting applications in the context of verification and certification of mobile code. For instance, the code receiver can use cost information in order to decide whether to reject mobile code which has too large cost requirements in terms of computing resources (in time and/or space) or billable events (SMSs sent, bandwidth required). Existing cost analyses for a variety of languages describe the resource consumption of programs by means of Cost Equation Systems (CESs), which are similar to, but more general than recurrence equations. CESs express the cost of a program in terms of the size of its input data. In a further step, a closed form (i.e., non-recursive) solution or upper bound can sometimes be found by using existing Computer Algebra Systems (CASs), such as Maple and Mathematica. In this work, we focus on cost analysis of Java bytecode, a language which is widely used in the context of mobile code and we study the problem of identifying variables which are useless in the sense that they do not affect the execution cost and therefore can be ignored by cost analysis. We identify two classes of useless variables and propose automatic analysis techniques to detect them. The first class corresponds to stack variables that can be replaced by program variables or constant values. The second class corresponds to variables whose value is cost-irrelevant, i.e., does not affect the cost of the program. We propose an algorithm, inspired in static slicing which safely identifies cost-irrelevant variables. The benefits of eliminating useless variables are two-fold: (1) cost analysis without useless variables can be more efficient and (2) resulting CESs are more likely to be solvable by existing CASs.

Resource-Driven CLP-Based Test Case Generation

“…In particular, the enhancement must ensure that the variables involved in the creation of new arrays (and those on which they depend) are added to the abstraction. This information can be statically approximated [2,15,16].…”

Analyzing Program Termination and Complexity Automatically with AProVE

“…Applying this program to count how often the number 4 occurs in the list [1,4,7] yields the rewrite steps…”

Conditional termination of loops over heap-allocated data

“…We consider S * and not S since accesses in S * \ S might indirectly affect the values of fields in S. Note that any subset chosen leads to a safe transformed program since the lack of some fields only implies computing less precise information. For instance, for the sake of efficiency, one can select only the fields that might affect the termination behaviour of the program (see, e.g., the approximation of [7]). …”

“…In what follows, variables are named using this convention: i, j represent integer variables; a an array of integers; x, y, z reference variables; and, xs an array of H COSTA AProVE Julia Tp Tm Tc Tp Tm Tc Tp Tm Tc (1) x.fi yes yes yes yes yes yes -yes unk (2) x.fy.fi yes yes yes yes yes yes -yes unk (3) x.fy.fz.fi yes yes yes yes yes yes -unk unk (4) a[i] yes yes yes unk yes yes -unk unk (5) fa[i] yes yes yes unk yes yes -unk unk (6) a[x.fi] yes yes yes unk yes yes -unk unk (7) x.fa[x.fi] yes yes yes unk yes yes -unk unk (8) xs [i].fi yes yes yes unk yes yes -unk unk…”