Class invariants as abstract interpretation of trace semantics

Transcription

1 Computer Languages, Systems & Structures ( ) Class invariants as abstract interpretation of trace semantics Francesco Logozzo École Polytechnique, F-91128, Palaiseau, France Received 21 January 2005; accepted 21 January 2005 Abstract We present a generic framework for the automatic and modular inference of sound class invariants for class-based object-oriented languages. We define a trace-based semantics for classes which considers all possible orderings, with all possible arguments, of invocations of all the methods of a class. We prove a correspondence theorem between such a semantics and a generic, trace-based, semantics for complete object-oriented programs. We express state-based class invariants in a fixpoint form by considering an abstraction of the class semantics, and we show how class invariants can be automatically inferred exploiting a static analysis of the methods. Furthermore, we address the problem of inferring a subclass invariant without accessing to the parent code, but just to its invariant Published by Elsevier Ltd. Keywords: Abstract interpretation; Class invariant; Object-oriented programming; Optimization; Static analysis; Trace semantics; Verification 1. Introduction A class is correct or incorrect not by itself, but with respect to a specification. For instance, a specification can be the absence of runtime errors, such as null-pointers deference or the absence of uncaught exceptions. More generally, a specification can be expressed in a suitable formal language. The software engineering community [1] proposes to annotate the source code with class invariants, method preconditions and postconditions in order to specify the desired behavior of the class. A class invariant is a property valid for each instance of the class, before and after the execution of any method, in any context. A method Tel.: ; fax: address: francesco.logozzo@polytechnique.fr /$ - see front matter 2005 Published by Elsevier Ltd. doi: /j.cl

2 2 F. Logozzo / Computer Languages, Systems & Structures ( ) precondition is a property satisfied before the execution of the method and a postcondition is a property valid just after its execution. The natural question with such an approach is: Does the class respect its specification?. The traditional approach is to monitor the assertions, so that for instance the preconditions and the class invariant are checked before the execution of a method. Such an approach has many drawbacks. For example, it requires checking arbitrary complex assertions so that it may introduce a non-negligible slowdown at runtime. Moreover it is inherently not sound. In fact the code must be executed in order to test if an assertion is violated or not. However, program execution or testing can only cover finitely many test cases so that the global validity of the assertion cannot be proved. Therefore the need for formal methods arises. The approach based on abstract interpretation consists in computing an approximation of the class semantics and then to check whether it satisfies the specification. In particular if a sound class invariant, which is inferred from the program source, matches the specification then the class itself matches the specification (because of soundness). Therefore a static analyzer capable of inferring sound class invariants can be used as an effective verification tool, [2]. Furthermore, class invariants can be used to optimize the compiled-code, e.g., to drop superfluous exception handlers or synchronizations, and for code documentation. In this paper, we present a framework for the modular inference of class invariants. We define a semantics of traces for a class in isolation and we prove it sound and complete w.r.t. a trace semantics for a whole object-oriented program. We consider an abstraction that considers the reachable states and we give the fixpoint characterization of the strongest state-based class invariant. In general such an invariant is not computable, so that we consider a further abstraction for the automatic inference of class invariants. Next we extend the framework in order to cope with subclassing, and in particular in order to infer subclass invariants without accessing to the parent s code Introductory example In order to illustrate the results of our work, let us consider the classes in Figs. 1 and 2. The first class, Stack, is the implementation of a stack parametrized by its size, specified at object creation time. It provides methods for pushing and popping elements as well as testing if the stack is empty or full. Moreover, as the internal representation of the stack is hidden a stack object can only be manipulated through its methods. The second class, StackWithUndo extends the first one by adding to the stack the capability of performing the undo of the last operation. The comments in the figures are automatically derived when our framework is instantiated with the Polyhedra abstract domain [3], refined with trace partitioning [4]. In particular, for the Stack we are able to discover the class invariant Inv without any hypothesis on the class instantiation context. The invariant Inv guarantees that the array stack is never accessed out of its boundaries. This implies that the out-of-bounds exception is never thrown (verification) so that the bounds checks at lines 22 and 28 can be omitted from the generated bytecode (optimization). The class invariant for StackWithUndo, SubInv, states that the parent class invariant is still valid and moreover the field undotype cannot assume values outside the interval [ 1, 1]. It implies that the method undo will never raise the exception StackErr. Once again this information can be used for verification (if a class never raises an exception Exc, then the exceptional behavior described by Exc is never shown) and for optimization (as the exception handling can be dropped). It is worth noting that SubInv is obtained without accessing to the parent code but just to its class invariant.

3 F. Logozzo / Computer Languages, Systems & Structures ( ) 3 class StackError extends Exception {} class Stack { // Inv : 1 < = size && // 0 < = pos < = size && // size=stack.length } protected int size, pos; protected Object[ ] stack; Stack(int size) { this.size = Math.max(size,1); this.pos = 0; this.stack = new Object[this.size]; } boolean isempty() { return (pos < = 0); } boolean isfull() { return (pos > = size); } Object top() throws StackError { if (!isempty()) // 0 < = pos-1 < stack.length return stack[pos 1]; else throw new StackError(); } void push(object o) throws StackError { if(!isfull()) { // 0 < = pos < size stack[pos++] = o; } else throw new StackError(); } void pop() throws StackError { if(!isempty()) pos ; else throw new StackError(); } Fig. 1. A class implementing a stack. Finally, let us consider the class Test in Fig. 3 which creates an instance of StackWithUndo. Using the properties inferred about StackWithUndo, and not its code, we can show that the exception StackError is never thrown. Therefore, the code inside the exception handler is never reached so that the program always prints ok! on the console Paper structure In Section 2, we introduce the mathematical background used in the rest of the paper. In Section 3, we define the concrete semantics for object-oriented programs and classes in isolation and in Section 4, we prove a correspondence theorem between the two semantics. In Section 5, we present the abstraction of the class concrete semantics for the inference of state-based class invariants. In Section 6, we discuss the

4 4 F. Logozzo / Computer Languages, Systems & Structures ( ) class StackWithUndo extends Stack { 5 // SubInv : Inv && -1 < = undotype < =1&& // if undotype == 1 then 0 < pos // else if undotype == 0 then 0 < = pos < = size // else if undotype == -1 then pos < size protected Object undoobject; protected int undotype; StackWithUndo(int x) { super(x); undotype = 0; undoobject = null; } void push(object o) throws StackError { undotype = 1; super.push(o); } void pop() throws StackError { if(!isempty()) { undotype = 1; undoobject = stack[pos 1]; } super.pop(); } // StackError never thrown void undo() throws StackError { if(undotype == 1) { super.push(undoobject); undotype = 0; } else if (undotype == 1) { super.pop(); undotype = 0; } } } Fig. 2. A subclass of Stack with undo. complexity of the algorithm for the inference of class invariants. In Sections 7 and 8, we extend our work to cope with inheritance, and in particular for the inference of subclass invariants modular w.r.t. the base class. Finally, in Section 9 we discuss the related work and in Section 10 we present the conclusions and the future work. 2. Background In this section, we introduce the mathematical background used in the rest of the paper. We fix the notation and we recall some well-known results in lattice theory, fixpoint theory and abstract interpretation theory.

5 F. Logozzo / Computer Languages, Systems & Structures ( ) 5 class Test { public static void main(string args[ ]) { 5 StackWithUndo s = new StackWithUndo(10); } } try{ for(int i=0; i < 10; i++) if(math.random()< 0.5) s.push(new Integer(i)); else s.undo(); } catch(stackerror e) { // Unreachable code System.out.println("Error in stack operations!"); return; } System.out.println("ok!"); Fig. 3. A class that uses StackWithUndo Notation and basic definitions We use the notation of denoting sets with capital letters and elements of sets with the sans serif font. So, when e is a member of the set S we write e S or S e. We denote with N the set of natural numbers, with Z the set of integer numbers, with B the set of boolean values. Given two sets U and V, the Cartesian product is U V. A relation R between U and V is a subset of the Cartesian product, R U V, and a relation RonUis R U U. We write urv to mean u, v R. We say that u is in relation R with v if urv holds. The set of all u which are in relation R with some v is called the domain of R, dom(r), and it is defined as dom(r) ={u U v V. urv}. In a similar way, the co-domain or the range of a relation, range(r), is defined as range(r) ={v V u U. urv}. A partial order on a set D is a relation on D which is reflexive, antisymmetric and transitive. A set with a partial order defined on it is called a partially ordered set, poset, or, with an abuse of language, simply a partial order. We denote it as D,. A relation on D which is reflexive and transitive is called a preorder. Given a poset D, and a subset U of D, we say that an element d D is an upper bound for U if u U. u d. We say that d D is the least upper bound of U, denoted by U, if it is an upper bound and any upper bound d D is such that d d. An element u U is the largest element of U if u is an upper bound for U. It is worth noting that because of the antisymmetric property, if the largest element exists then it is unique. If it exists, we denote the largest element of D with. Lower bounds, greatest lower bounds and smallest elements are defined dually. In particular, if it exists, we denote the smallest element of D with. A poset D, is called a lattice if any two elements of D have both a greatest lower bound and a least upper bound. If a poset admits greatest lower bounds and least upper bounds even for infinite sets then it is a complete lattice. In such a case we write either D,,,,,

6 6 F. Logozzo / Computer Languages, Systems & Structures ( ) or, when the lattice operators are clear from the context, simply D,. We say that the operator is complete if any subset U of D admits the least upper bound U. A poset D, is said to satisfy the ascending chain condition (ACC) if every ascending chain d 1 d 2... of elements of D is eventually stationary, that is, there is some positive integer n such that m>n. d m = d n Functions and fixpoints Given two sets D and R, a relation f D R is called a function if df r 1 and df r 2 imply r 1 = r 2 for any d, r 1, and r 2. We specify functions using the λ-notation, i.e., λx.b defines a function with an input x and an output given by the expression B, parametric w.r.t. x. Given a function f, ay dom(f ) and a v range(f ), the update of f is the function defined as f [y v]=λx. if x = y then v else f(x). We denote the set of all the functions with a domain D and a range included in R as [D R] ={f f is a function, dom(f ) = D, range(f ) R}. Given two functions f [D R] and g [R C] their composition is g f [D C]. If D,, and R,, are complete lattices, then we say that a function f [D R] is monotonic if it preserves the order of the elements: d 1, d 2 D. d 1 d 2 f(d 1 ) f(d 2 ) and that it is a join-morphism if it preserves least upper bounds: d 1, d 2 D. f (d 1 d 2 ) = f(d 1 ) f(d 2 ). Given a set D and a function f [D D], a fixpoint of f is an element d D such that f(d) = d. If f is defined over a partial order D,, then an element d D is the least fixpoint if d = f(d) and d D. d = f(d ) d d. Given a function f defined over a poset D, and an element d D, we denote with lfp d f, the least fixpoint of f w.r.t. the order larger than d, if it exists. Sometimes, when the order and the element are clear from the context, we will simply write lfpf. A main result of Tarski [5], is that a monotonic function defined over a complete lattice admits a least and greatest fixpoint: Theorem 1 (Tarski s fixpoint Theorem [5]). Let D,,,,, be a complete lattice and let f [D D] be a monotonic function. Then the set F ={d D f(d) = d} is a non-empty complete lattice w.r.t the order. Furthermore lfp f = {d D f(d) d} Traces Given a (possibly infinite) set Σ of states and an Ω / Σ, a trace τ is a function τ [N Σ {Ω}] which respects the prefix condition: n N. τ(n) = Ω i>n.τ(i) = Ω. This means that if a trace is undefined for an n N, then it is undefined for all the successors of n too. We say that a trace τ is finite if n N. τ(n) = Ω. If not we say that it is infinite. The sets of finite traces over Σ is denoted by T(Σ). The length of a trace is given by a function len [T(Σ) N] defined as len = λτ. min{n N τ(n) = Ω}. A trace can be isomorphically represented by a succession of states. If τ is finite then we can write τ = σ 0 σ 1 σ 2 σ n where n = len(τ) 1 and i [0...n]. σ i = τ(i). The empty trace is denoted by ε and a trace of length one is just a state σ Σ. Given a trace τ, we assume that τ ε = τ. Given a set of traces T T(Σ), aτ T is a maximal trace of T if τ T. ( i [0...len(τ) 1]. τ(i) = τ (i)), (len(τ)<len(τ )). Traces can be labeled. Let us consider a set of states in the form of Σ = Σ L, where L is a set of labels that contains the empty label ε. Then, a trace τ T(Σ)

7 F. Logozzo / Computer Languages, Systems & Structures ( ) 7 in the form of τ = σ 0, ε σ 1,l 1 σ 2,l 2... can be rewritten as a labeled trace l 1 l 2 τ = σ 0 σ 1 σ 1... Sometimes, with an abuse of notation we tacitly assume the set of labels L is given, so that we write T(Σ ) instead of the more verbose T(Σ L). Given a program P, the associated transition relation P Σ Σ, and a set of initial states S 0, the partial execution traces semantics of P can be expressed as a fixpoint: P Theorem 2 (Fixpoint partial traces semantics, Cousot and Cousot [6]). Let Σ be a set of states, Σ Σ be the transition relation associated with a program P, S 0 Σ be a set of initial states and F [P(Σ) P(T(Σ)) P(T(Σ))] be F(S 0 ) = λx.s 0 {σ 0...σ n σ n+1 σ 0... σ n X, σ n P σn+1 }. Then the partial trace semantics of P, tr P [P(Σ) P(T(Σ))], is tr P (S 0 ) = lfp F(S 0) = F i (S 0 ). i ω With a slight abuse of notation, in the following we often write for, P so that in particular we do not differentiate between the transition relation P and the used for denoting traces Abstract interpretation The abstract interpretation theory [7] formalizes the approximation correspondence between the concrete semantics s P of a syntactically correct program P and an abstract semantics s P which is a safe approximation on the concrete semantics. The concrete semantics belongs to a concrete semantic domain D which is a partially ordered set D,. In such a setting, the partial order formalizes the loss of information, e.g. the logical implication. The abstract semantics also belongs to a partial order D,, which is ordered by the abstract version of the concrete approximation order. We use the notation to tag the abstract counterparts for concrete entities with an over-line. For instance, D and are the abstract counterparts for the concrete domain D and the order. Definition 1 (Galois connections, Cousot and Cousot [7]). Let D, and D, be two partial orders and let α [D D] and γ [ D D].If d D. d D. α(d) d d γ( d) (1)

8 8 F. Logozzo / Computer Languages, Systems & Structures ( ) then we say that α, γ is a Galois connection and we denote it as D, γ D,. α Example 1 (Reachable states abstraction, α Σ ). Let Σ be a set of states. Then P(T(Σ)),,, T(Σ),, γ Σ P(Σ),,, Σ,,, α Σ where the abstraction and the concretization functions are defined as follows: α Σ (T ) ={σ Σ τ T. i. τ(i) = σ}, γ Σ (S) ={τ T(Σ) i. τ(i) = Ω τ(i) S}. Example 2 (Final states abstraction, α ). Let Σ be a set of states. Then P(T(Σ)),,, T(Σ),, γ P(Σ),,, Σ,,, α where the abstraction and the concretization functions are defined as follows: α (T ) ={σ Σ τ T. τ is maximal, τ(len(τ) 1) = σ}, γ (S) ={τ T(Σ) n 0. τ(n) S,τ(n + 1) = Ω}. Galois connections enjoy several properties. Lemma 1 (Composition). If D, γ 1 D 1, 1 and D 1, 1 γ2 D, then D, D,. α 1 α 2 α 2 α 1 Lemma 2 (Preservation of bounds). If D, and D, are complete lattices and if D, γ D, α then α is a complete join-morphism and γ is a complete meet-morphism. Lemma 3 (Liftingto the higher-order). Let D i, i γ i D i, i, D o, o γo D o, o. α i α o m m Furthermore, let [D i Do ] and [ D i D o ] be sets of monotonic functions. Then where and [D i m Do ], γ m [ D i D o ],, α α(f ) = λ v. α o f γ i ( v) γ( f)= λv. γ o f α i (v). γ 1 γ 2

9 F. Logozzo / Computer Languages, Systems & Structures ( ) 9 The concrete and abstract semantics of a program P are usually given in a fixpoint form as s P =lfpt P and s P =lfp t P, where the semantic transformers t P and t P are monotonic functions, respectively, on [D D] and [ D D]. If the concrete and abstract transformer satisfy the local commutative condition t P γ γ t P then the next theorem ensures the soundness of the abstract semantics: Theorem 3 (Fixpoint transfer, Cousot and Cousot [6]). Let D, and D, be complete lattices. Let t P and t P be monotonic functions defined, respectively, on [D D] and [ D D]. If D, γ D, and if t P γ γ t P then α s P = lfp t P γ(lfp t P ) = γ( s P ). The abstract fixpoint lfp t P is computed iteratively. If the abstract domain D enjoys the ACC condition then the computation is guaranteed to terminate. If not the sequence convergence must be assured using a widening operator [7]. Informally, a widening is a kind of join for which every increasing sequence is stationary after a finite number of steps and that extrapolates the sequence limit. Formally Definition 2 (Widening, Cousot and Cousot [7]). A widening [ D D D] is an operator such that d1, d2 D. d1 d1 d2 and d2 d1 d2 and for all increasing chains d0 d1... di+1...the increasing chain defined by ȳ 0 = d0, ȳ 1 =ȳ 0 d1...,ȳ i+1 =ȳ i di+1... is not strictly increasing. 3. Concrete semantics The goal of a static analysis is to provide an effective computable approximation of the concrete semantics [8]. Therefore, the first step of a static analysis is the definition of a concrete semantics. We define two semantics. The first one is a trace semantics for a whole object-oriented program and the second one is a trace semantics for a single class in isolation. We study the relation between the two semantics, and in particular we show the soundness and the completeness of the class semantics w.r.t. the whole-program semantics Syntax A class is a description for a set of objects, instances of the class. The class source is provided by the programmer, who specifies the class constructor, the fields and the methods. Therefore, the class syntax can be modeled as a triplet: Definition 3 (Class). A class A is a triplet init, F, M where init is the class constructor, F is a set of variables and M is a set of function definitions.

10 10 F. Logozzo / Computer Languages, Systems & Structures ( ) We denote by C the set of all the classes. It is worth noting that for the sake of generality in the definition above we do not require to have typed fields or methods. Moreover, we assume that all the class fields are protected. This is done to simplify the exposition, and it does not cause any loss of generality: in fact any access to a field f can be simulated by a couple of methods set_f/get_f. Additionally, we also assume that a class has just a single constructor, the generalization to an arbitrary number of constructors being straightforward. An object-oriented program is a set of classes. In particular, it is composed by a main class and a library: Definition 4 (Object-oriented program). An object-oriented program P is a pair P = A main, L where A main C is the main class and L C is the program library. With an abuse of notation, given an object-oriented program P= A main, L in the following we write A P if A = A main or A L Semantic domains The first step in specifying the semantics is the definition of the semantic domains. Intuitively we need a domain that models that an object has its own identity and environment. Moreover, in order to be realistic, we need to express object aliasing. In order to fulfill the above requirements, we consider a domain whose elements are pairs of environments and stores: an environment is a map from variable names to memory addresses, and a store is a map from addresses to memory elements. In its turn, a memory element can be a primitive value or an environment. The object environment is stored in a certain memory location whose address represents the object identity. In such a setting, two distinct variables are aliases for an object if they refers to the same object, i.e., the same memory address. We can formalize what said above: Definition 5 (Environment, Env). Let Var be a set of variables and let Addr N be a set of addresses. Then the set of environments is Env =[Var Addr]. Definition 6 (Store, Store). Let Val be a set of values such that Env Val. Then the set of stores is Store =[Addr Val]. Given a state ρ Env Store, ρ = e, s and a variable x, we write ρ(x) to mean s(e(x)). It is worth noting that in the above definition we require Env to be included in the possible memory values, so that given an object, i.e. a memory address, we can access its environment through the store. Moreover, in order to be as generic as possible we put no further constraint on the values that can be stored in memory. Thus, for example, the C++ memory model can be obtained once we have that Addr Val. We assume that a state contains some special variables, namely: the pointer to the current object, the current program counter [9, Section 3.5.1], the call stack, [9, Section 3.6], and the method input value and the method return value, if any. This is summarized by the following definition: Definition 7 (Special variables). Let ρ = e, s Env Store and {this, pc, callstack, inval, retval} Var. Then e(this) is the pointer to the current object;

11 F. Logozzo / Computer Languages, Systems & Structures ( ) 11 ρ(pc) is the program counter; ρ(callstack) is the call stack; ρ(inval) is the input value of the current method; ρ(retval) is the value returned by the current method. In general, from the call stack it is possible to infer the current method (e.g. [9, Section 3.6]) and the height of the call stack. So, with an abuse of notation, we denote the current method of a state ρ with ρ(curmethod) and the height of the call stack with ρ(stackheight) Whole-program semantics The semantics of an object-oriented program P is a set of partial execution traces that represents the executions of the program starting from a set of initial states R 0. According to Theorem 2, it can be expressed in fixpoint form as follows: Definition 8 (Object-oriented program semantics, w ). Let P = A main, L be an object-oriented program, (Env Store) (Env Store) be a transition relation, main be a method of A main, pc in be the entry point of main and R 0 P(Env Store) be a set of program initial states, i.e. such that ρ 0 R 0. ρ 0 (curmethod) = main, ρ 0 (pc) = pc in. Then the semantics of P, w P [P(Env Store) P(T(Env Store))] is w P (R 0 ) = lfp λx. R 0 {ρ 0...ρ n ρ n+1 ρ n+1 Env Store, ρ 0...ρ n X, ρ n ρ n+1 }. It is worth noting that for the sake of generality we do not explicitly define the transition relation as it depends upon the particular considered object-oriented language. Examples of can be found in [10] for the Java bytecode, in [11] for a core object-oriented language, and in [12] for a core, sequential, Java. The transition relation and Theorem 2 can be used to express the semantics of the constructor and of the methods in fixpoint form as Definition 9 (Method trace semantics, w m ). Let A = init, F, M, m be init or m M. Let pc in and pc exit be, respectively, the entry point and the exit point of m. Furthermore, let (Env Store) (Env Store) and let R 0 P(Env Store) be a set of method initial states, i.e. ρ 0 R 0. ρ 0 (pc) = pc in. Then, the trace semantics of m, w m m [P(Env Store) P(T(Env Store))] is w m m (R 0 ) = lfp λx. R 0 {ρ 0...ρ n ρ n+1 ρ n+1 Env Store, ρ 0...ρ n X, ρ n ρ n+1 } {ρ 0...ρ n ρ 0...ρ n X, ρ 0 (stackheight) = ρ n (stackheight), ρ n (curmethod) = m, ρ n (pc) = pc exit }.

12 12 F. Logozzo / Computer Languages, Systems & Structures ( ) The trace semantics of a method m is such that the maximal traces end with a state such that the program counter refers to the exit point of m and the height of the stack is the same as the entry point. This last condition implies that we consider the exit point of m at the same level of recursion as the input. Furthermore, note that (i) if the invocation of a method m does not terminate, then w m m contains infinitely many partial, i.e. finite, executions traces; and (ii) as we does not constraint the transition relation, it is possible that for some state ρ n, ρ 0 (stackheight)>ρ n (stackheight) Class trace semantics We define the semantics of a class as the set of all the semantics of all the objects that are instances of the class. In its turn, the semantics of an object is the set of traces that correspond to the evolution of the object internal state. In this section, we give the fixpoint characterization of the class semantics. The soundness results of the next sections will be given with respect to this concrete semantics. The semantics of an object is given on the top of the semantics of the class constructor and of the class methods. In its turn, the semantics of the constructor and the methods are obtained as an abstraction of the trace semantics of Definition 9. When a class is instantiated, for example by means of the new construct, the class constructor is called to set up the new object internal state. The context, that creates the object, passes to the constructor the actual parameters and the store. The constructor initializes the object fields and returns the new object environment and the modified store. Such a behavior is formalized by the following definition: Definition 10 (Constructor semantics, i ). Let D in Val be the semantic domain for the input values, e 0 be the initial environment, a in, a pc be fresh memory addresses, pc 0 be the constructor entry point and α the abstraction function defined in Example 2. Then the semantics of the class constructor, i init [D in Store P(Env Store)],is i init = λ(v in, s). let ρ 0 = e 0 [inval a in, pc a pc ], s[a in v in, a pc pc 0 ] in α (w m init ({ρ 0 })). Here are some remarks on the above definition. First, the semantics i init is essentially an abstraction of w m init in which just the initial state and the final states are retained. Second, the output is a set of pairs as in general the execution of the constructor may be non-deterministic. Third, the generalization for a tuple of input values is straightforward. Example 3 (Constructor semantics). Let us consider the C++ class in Fig. 4. The class constructor creates a new environment consisting of two entries, one for pos and the other for goright. The semantics of the Walk constructor is i Walk() = λ(, s). { e 0 [pos a i, goright a b, pc a pc ], s[a i 0, a b true, a pc 11] }, where e 0 is an environment, a i, a b and a pc are fresh memory locations and 11 is the exit point of the constructor. Once an object has been created, the context can interact with it. When the context invokes a method, it passes some input values, the object environment and the store. In its turn, the method returns a value,

13 F. Logozzo / Computer Languages, Systems & Structures ( ) 13 class Walk { // Implements a random walk private: int pos; bool goright; public: Walk() { pos = 0; goright = true; }; void dostep() { if(goright) pos += 4; else pos =6; }; bool* getdirpointer() { return &goright; }; }; Fig. 4. An example of a C++ class implementing a random walk. the new object environment and the modified store. The behavior of the method can be formalized by the following definition: Definition 11 (Method semantics, m ). Let D in, D out Val be the semantic domains for the input values and the output values, a in and a pc be fresh memory addresses, m be a method, pcm be the m entry point and α be the abstraction function defined in Example 2. Then the semantics of a method m, m m [D in Env Store P(D out Env Store)], is m m = λ(v in, e, s). let ρ 0 = e[inval a in, pc a pc ], s[a in v in, a pc pcm] in let R f = α (w m m ({ρ 0 })) in { ρ f (retvalue), e f, s f ρ f = e f, s f R f }. Here are some remarks on the above definition. First, it is essentially an input/output abstraction of w m m. Second, the execution of the method may present some kind of non-determinism. Third, in order to model procedural methods, i.e. methods that does not return any value, we assume to have a special void value D out. Fourth, if Addr D out then the method may expose a part of the object internal state to the context. Example 4 (Method semantics). The class in Fig. 4 has two methods. The first, dostep, adds or subtracts a value to pos depending whether goright is true or not. It does not return any value to the caller and it does not change the object environment. Hence its semantics is m dostep = λ(, e, s). {, e, s[a pc 15, e(pos) if s(e(goright)) = true then s(e(pos)) + 4 else s(e(pos)) 6] }.

14 14 F. Logozzo / Computer Languages, Systems & Structures ( ) It is worth noting that we update the value of the program counter to the exit point of modify, i.e. a pc = 15. The method getdirpointer is a helper method that returns a pointer to a part of the object state, namely to goright. Hence, this method exposes a part of the object state but it does not modify neither the environment nor the store (except for the program counter). The semantics of getdirpointer is: m getdirpointer = λ(, e, s). { e(goright), e, s[a pc 18] } Object semantics The semantics of an object is given by a set of traces. Intuitively, each trace represents a possible evolution history of the object. The first state represents the object just after its creation. Each further state is the result of an interaction between the object and a context. This interaction can happen in two ways (1) the context invokes a method of the object; or (2) it modifies a memory location that is reachable from the object environment. We refer to the former as direct interaction and to the latter as indirect interaction. We do not consider a third possible kind of interaction, namely the one in which the context accesses the object fields unless the object has revealed them before. For instance, this is the case of a context that may guess the memory addresses where the object fields are stored. For each interaction with the context, we consider the environment and the store after the interaction, the eventual value returned by a method execution and the set of addresses that escapes from the object. Formally, we define the interaction states as Definition 12 (Interaction states). The set of interaction states is Σ = Env Store D out P(Addr). The initial interaction states are the states reached just after the creation of a class, i.e. after the invocation of the class constructor: Definition 13 (Initial states, S 0 v, s ). Let v D in be an input value, s Store be a store and o be an instance of a class A. Then the set of initial states of o is: S 0 v, s ={ e, s,, i init (v, s) e, s }. It is worth noting that we use to model the fact that the class constructor does not return any value. As a consequence, it does not expose any address to the context. Example 5 (Initial states). Let us instantiate Walk in some store s. Then, omitting the special variables, the initial states are given by S 0, s ={ e, s,, e =[pos a i, goright a b ], s = s[a i 0, a b true]}. The successors of a state are given by a transition function next. Given a state σ the intuitive meaning of next(σ) is to consider all the states that are result of an interaction of σ with a context. Thus, as there are two kinds of interaction, next will consist of two parts: one corresponding to the direct interactions, and the other to the indirect ones. Moreover, in the following we will be interested to know whether a

15 F. Logozzo / Computer Languages, Systems & Structures ( ) 15 state is a consequence of a direct or an indirect interaction. For that purpose we tag each successor of σ with a label. A label can either be a pair consisting of the name of the invoked method and the input value, or a special term κ to denote an action of the context. Thus, the set of labels is Definition 14 (Transition labels, Label). The set of labels is defined as Label = (M D in ) {κ}. The transition function, next [Σ P(Σ Label)], is made up of two components: next dir and next ind. The direct interaction happens when the context invokes a method of the object. The context may invoke any method with any input value. Therefore, the transition function for the direct interaction is Definition 15 (Direct interaction, next dir ). Let e, s, v, Esc Σ be an interaction state. Then the function next dir [Σ P(Σ Label)] is defined as next dir ( e, s, v, Esc ) = { e, s, v, Esc, m, v in m M, v in D in, m m (v in, e, s) v, e, s, Esc = Esc reachable(v, s )}. In the above definition we made use of the helper function reachable, that given an address v and a store s, determines all the memory addresses that are reachable from v. Intuitively, if a method returns an address, then the context can access it so that the context can arbitrarily modify the value of the store at that point. In that case we say that the object exposes v or that v escapes the scope of the object. For the sake of simplicity, we assume that the only way that an object has to expose a part of its state is by returning an address to the context. At its turn, the memory element s(v) = v may be (the identity of) an object. Then s(v ) is its environment, and (the addresses of) all its fields escape. And so on recursively: Definition 16 (reachable). The function reachable [(D out Store) P(Addr)] is recursively defined as follows: reachable(v, s) = if v Addr then {v} {reachable(e (f), s) B. B = init, F, M, f F, s(v) is an instance of B, s(s(v)) = e } else. Example 6 (Direct interaction). Let us apply the above definitions to determine the successors of the state σ 0 S 0, s. In that case, the context can arbitrarily decide to invoke one of the methods of Walk. Thus, the successors of σ 0, ignoring special variables, are: next dir (σ 0 ) = { e, s,,, dostep, σ 0 = e, s,,, m modify (, e, s), e, s, s = s[a i 4]} { e, s, a b, {a b }, getdirpointer, σ 0 = e, s,,, m getdirpointer (, e, s) a b, e, s }. If the context invokes dostep then the store location corresponding to the field pos is updated. On the other hand, if the context invokes getdirpointer, it returns the goright s address, while the environment and the store remain unchanged. Thus a b escapes its scope.

16 16 F. Logozzo / Computer Languages, Systems & Structures ( ) Once an address escapes from an object, the context is free to access the corresponding memory location and to modify it arbitrarily. The transition function for the indirect interactions formalizes this intuition Definition 17 (Indirect interaction, next ind ). Let e, s, v, Esc Σ be an interaction state. Then the function next ind [Σ P(Σ Label)] is defined as next ind ( e, s, v, Esc ) = { e, s,, Esc, κ a Esc. s update(a, s)}. We used the function update in the definition above. It takes as input a pair of memory address a and a store s and it returns the set of the stores where the memory element s(a) takes all the possible values in the values domain Definition 18 (Update). The function update [Addr Store P(Store)] is defined as update(a, s) ={s v Val. s = s[a v]}. The class constructor does not return any value. Therefore, no address escapes the object scope just after its creation. So, if we refer to the running example, it is immediate to see that if σ 0 S 0, s then next ind (σ 0 ) =. This is a particular case of a more general result, that states that if the object methods do not expose any internal address, then no indirect interaction can happen Lemma 4. Let σ = e, s, v, be an interaction state. Then next ind (σ) =. Proof. It is immediate from Definition 17. The transition function for the indirect interaction only takes into account the modification of one memory location at time. However, an indirect interaction that affects several memory addresses can be simulated by the successive applications of the next ind function. This is expressed by the following lemma: Lemma 5. Let σ = e, s, v, Esc and σ = e, s[a 0 v 0,...a n v n ],, Esc, be two interaction states. If i.a i Esc and i, j. i = j a i = a j then σ 1 Σ... σ n 1 Σ. σ 1, κ next ind (σ), σ 2, κ next ind (σ 1 ),... σ, κ next ind (σ n 1 ). Proof. The proof is by induction on n. If n = 0 the thesis follows immediately by the definition of next ind and update. Otherwise, if n>0, the induction hypothesis implies that there exists a succession of states σ 1...σ n 1 such that σ n 1 = e, s[a 0 v 0,...a n 1 v n 1 ], v, Esc. Then, as all the addresses are distinct, next ind (σ n 1 ) contains an element σ, κ. It is now possible to define the transition function next, that sums up the direct and indirect interactions: Definition 19 (Transition function, next). Let σ Σ be an interaction state. Then the transition function next [Σ P(Σ Label)] is defined as next(σ) = next dir (σ) next ind (σ).

17 F. Logozzo / Computer Languages, Systems & Structures ( ) 17 Once the transition function is set up, the semantics of an object can be expressed as a least fixpoint on the complete lattice P(T(Σ)),,, T(Σ),,. Essentially, the semantics of an object is the set of the traces that encode all the interactions between the object and all the possible contexts it can be instantiated in. Stated otherwise, the semantics of an object includes all the possible orderings of invocations, with all the possible values, of all the methods in the object Definition 20 (Object fixpoint semantics, o o ). Let v Val be an object input value and s Store a store at object creation time. Then the object semantics o o [D in Store P(T(Σ))] is defined as o o (v, s) = lfp λt. S 0 v, s {σ 0 l 0 ln 1 σ n l σ Using Theorem 2 it is immediate to see that Theorem 4. Let σ 0 l 0 ln 1 σ n T,next(σ n ) σ,l }. (2) F = λt. S 0 v, s {σ 0 l 0 ln 1 σ n l σ σ 0 l 0 ln 1 σ n T,next(σ n ) σ,l }. Then o o (v, s) = ω n=0 F n ( ). Now, we can explain more formally what it means that the semantics of an object contains all the possible interactions between an object with any possible context. A generic context is free to interact with the object, by calling any method with any value or by arbitrarily modifying the value of the escaping addresses: the functions next dir and next ind take into account these cases. As a result, we have that o o is the most precise property for an object: it describes the behavior of an object during all his lifetime, for each invocation history and context. Therefore it is an object invariant. However, in general it is not computable so that we will need to perform some abstractions in order to obtain an effective object and hence class invariant Class semantics in fixpoint form As a class is a description of a set of objects, it is natural to define the semantics of a class C as the set that contains the semantics of all the objects that are instances of C. This is expressed by the next definition: Definition 21 (Class semantics, c A ). Let A be a class. Then its semantics c A P(T(Σ)) is c A = {o o (v, s) o is an instance of A, v D in, s Store}. As class invariant is a property that is satisfied by the semantics of all the objects that are instance of that class. In our setting, this is equivalent to say that it is satisfied by all the traces in the class semantics. Once again, the most precise class invariant is not computable, so that we need to perform some abstractions in order to obtain an effective analysis. The class semantics defined above can be expressed in a fixpoint form, i.e., the class semantics is the set of semantics of its instances. By definition, the semantics of each instance takes into account, among

18 18 F. Logozzo / Computer Languages, Systems & Structures ( ) the others, the interaction with other objects. In particular this is valid when the objects belong to the same class. Therefore, it is possible to flat together the semantics of the different instances without introducing new behaviors: Theorem 5 (Class semantics as fixpoint). The class semantics can be expressed in fixpoint form where c A = lfp F D in Store, F S =λt. {S 0 v, s v, s S} {σ 0 l 0 ln 1 σ n l σ σ 0 l 0 ln 1 σ n T,next(σ n ) σ,l }. Proof. By definition c A ={o o (v, s) v D in, s Store}. Applying in the order Definition 20, Theorems 4 and 2, we can rewrite the definition of the class semantics as follows: c A = = v,s D in Store lfp F { v, s } = v,s D in Store ω F n D in Store ( ) = lfp F D in Store. n=0 ω F n { v, s } ( ) n=0 4. Relation between w and c We are now left to study the relation between w P, the semantics of a whole object-oriented program, and c A, the semantics of a class. The main result of this section are Theorems 6 and 7, which state the soundness and the completeness of the class semantics w.r.t. the whole program semantics Abstraction We define an abstraction function that, given a trace τ T(Env Store) and an object o that belongs to a class A, cuts all the sub-traces of τ that do not involve the object o. First, we define the auxiliary function split o [T(Env Store) (Env Store) T(Env Store)] which, given a trace τ and an object o, finds the longest prefix of τ made up of states involving the execution of a method of o and returns a pair consisting of the last state of such a prefix and the remaining suffix of τ. Formally Definition 22 (split o ). Let o be an object and τ T(Env Store) and pc exit be the exit point of τ(0)(curmethod). Then split o [T(Env Store) (Env Store) T(Env Store)] is defined as split o (τ) = let n = min{i N τ(i)(pc) = pc exit, τ(i)(this) = o, τ(0)(stackheight) = τ(i)(stackheight)} in τ(n), τ(n + 1)... τ(len(τ) 1).

19 F. Logozzo / Computer Languages, Systems & Structures ( ) 19 Definition 23 (α o i ). Let o be an object, τ T(Env Store). Then αo i [(T(Env Store) Store) T(Env Store)] is defined as α o i = λ(τ, s last). ε if τ = ε, let ρ, τ =split o (τ) in let e, s =ρ if τ = e, s τ, e(this) = o, in ρ α o i (τ, s ) α o i (τ, s last ) e, s α o i (τ, s) if τ = e, s τ, e(this) = o, s /s(o) = s last/s(o), if τ = e, s τ, e(this) = o, s /s(o) = s last/s(o). The four cases of α o i can be explained as follows. The abstraction of the empty trace is the empty trace. If the first state of the trace involves the object o (i.e. e(this) = o), then it means we are inside some method m of o, so that we abstract away all the internal steps of the execution of m but the last and we apply recursively the abstraction to the rest of the trace. If the current object is not o, then we can distinguish two cases for the first state of τ. If the part of memory reached by the environment of o is not changed (i.e. s /s(o) = s last/s(o) ) then it can be dropped. If not, it must be kept. In the two cases we continue with the rest of the trace (i.e. τ ). The next abstraction maps the states of a trace to interaction states. Definition 24 (α o ). Let o be an object and τ T(Env Store). Then αo [(T(Env Store) P(Addr)) T(Σ)] is defined as α o = λ(τ, Esc). ε if τ = ε, let e, s =ρ in let Esc = Esc reachable(ρ(retval), s) in e, s, ρ(retval), Esc, ρ(curmethod), ρ(inval) α o (τ, Esc ) let e, s =ρ in e, s,, Esc, κ α o (τ, Esc) if τ = ρ τ, e(this) = o, if τ = ρ τ, e(this) = o. Finally, the abstraction α o [P(T(Env Store)) P(T(Σ))], given a set of execution states T, projects from the traces in T the states that are relevant to the object o, either by calling one of its methods or by modifying the value of a memory location reachable by the fields of o. Formally Definition 25 (α o ). Let o be an object, T T(Env Store) a set of execution traces and s be the empty store. Then the abstraction α o [P(T(Env Store)) P(T(Σ))] is defined as α o (T ) ={α o (αo i (τ, s ), ) τ T }. Lemma 6 (α o Is a complete -morphism). {T i T i T(Env Store)}. α o ( i T i ) = i αo (T i ).

20 20 F. Logozzo / Computer Languages, Systems & Structures ( ) Proof. Let {T i } a collection of set of traces. Then ( ) { α o T i = α o (αo i (τ, s ), ) τ } T i i i = i {α o (αo i (τ, s ), ) τ T i }= i α o (T i ). The previous lemma, and the properties of Galois connections, imply that there exists a unique concretization function γ o such that Lemma 7 (Soundness of α o ). P(T(Env Store)),,, T(Env Store),, γo α o P(T(Σ)),,, Σ,, Soundness and completeness of the class semantics We can now state the relation between the whole-program semantics w and the class semantics c. The first theorem essentially states that all the interactions that a program P performs on an object o instance of a class A are captured by c A. Theorem 6 (Soundness of c ). Let P be a whole object-oriented program, let A P and o be an instance of A. Then R 0 Env Store. τ T(Env Store). τ w P (R 0 ) τ c A. α o ({τ}) ={τ }. Proof. Let τ w P (R 0 ). By definition of w, τ = ρ 0... ρ n, with ρ o R 0.Ifois not an object instantiated in τ, then i [0..n]. τ(i)(this) = o, so that by definition of α o, α o ({τ}) ={ε}, so that the theorem is straightforwardly verified. If not, α o l 0 ({τ}) ={τ α } is such that τ α = σ 0... l k 1 σ k, with k n and i [0..k]. σ i Σ and either l i = κ or l i = m, v. The first state, σ 0 is the consequence of the object creation, i.e. of the constructor invocation. Therefore, as i init is built on the top of w m init, Definition 9 and Definition 13 imply that i [0..n]. ρ i = e i, s i. x Vars. σ 0 l i S 0 ρ i (x), s i. Now, consider for all the i 0 the sub-trace σ i σ i+1 of τ α.ifl i = κ then by definition of next ind, σ i+1 next ind (σ i ). Otherwise, l = m, v for some method m of A and v D in. Therefore, as next dir considers all the methods and all the possible input value, σ i+1 next ind (σ i ). To sum up, the fact that σ 0 S 0 ρ i (x), s i and that all the transitions of τ α may be mimicked by either next ind or next dir implies that τ α c A necessarily. Next theorem states that all the behaviors considered by c A are feasible. Theorem 7 (Completeness of c ). Let A be a class. Then τ T(Σ). τ c A P. ρ o Env Store. o instance of A. τ T(Env Store). τ w P ({ρ 0 }), α o ({τ }) ={τ}.

21 F. Logozzo / Computer Languages, Systems & Structures ( ) 21 l 0 Proof (Sketch). Let τ=σ 0... l n 1 σ n c A. The theorem is proved by constructing a suitable program P and initial state ρ 0. By definition of c A and Definition 13, it exists a pair v, s such that i init v, s = σ 0. As a consequence, we can build a ρ 0 = e, s such that e is an environment that satisfy s(e (inval))=v. The corresponding program P will contain the line o = new A(inVal). Then, the construction of the other lines of P goes on by considering the labels l 0,l 1,...l n 1 : i [0..n 1] if l i = m, v then P will κ contain the command o.m(v). If not, for a transition σ i σi+1 it will contain a sequence of assignments *a j = v wherea j is the address of the an escaped field value (obtained from the field Esc of σ i ) and v is the new value (obtained from the store in σ i+1, i.e. s i+1 (a j ) = v). By construction of ρ 0 and P the theorem is proved. 5. Abstract semantics for the inference of class invariants We abstract the semantics of classes in two steps. First we abstract the reachable states and we characterize the strongest, state-based, class invariant. Then, we show how any static analysis can be plugged in, so to obtain an effective algorithm for the automatic inference of class invariants Reachable states semantics We now proceed by defining an abstraction that forgets the trace histories, keeping just the states reachable in a computation. For example, let us consider the traces in Fig. 5. The traces on the left are abstracted by their states so that for instance the fact that σ 2 is a consequence of the execution of the method m i from one the initial state σ 1 is lost. On the other hand, the states reached in the computation are safely approximated, so that the state-based properties are preserved. As a consequence the abstraction is painless as far as we are interested in approximating the values that the fields of the objects can take, and, e.g. not their evolution over the time. Let us begin with some preliminary definitions. The semantics of a method can be lifted to set of states by considering all the states that are reachable through the execution of the method Definition 26 (Collectingmethod semantics, M ). Let m be a method and S P(Σ) a set of interaction states. Then the collecting method semantics of m, M m [P(Σ) P(Σ)] is defined as M m (S) ={ e, s, v, Esc e, s, v, Esc S,v in D in, m m (v in, e, s) v, e, s, Esc = Esc reachable(v, s )}. Next we define a function that given a set of interaction states returns all the possible indirect interactions between the context and the part of the internal object fields exposed to the context: Definition 27 (Context( )). Let S Σ be a set of interaction states. Then the indirect interaction of the states in S with the context is summarized by the function Context( ) [P(Σ) P(Σ)]: Context(S) ={ e, s,, Esc e, s, v, Esc S, a Esc. update(a, s) s }.