Resource control of object-oriented programs

A sup-interpretation is a tool which provides an upper bound on the size of a value computed by some symbol of a program. Sup-interpretations have shown their interest to deal with the complexity of first order functional programs. For instance, they allow to characterize all the functions bitwise computable in Alogtime. This paper is an attempt to adapt the framework of sup-interpretations to a fragment of oriented-object programs, including distinct encodings of numbers through the use of constructor symbols, loop and while constructs and non recursive methods with side effects. We give a criterion, called brotherly criterion, which ensures that each brotherly program computes objects whose size is polynomially bounded by the inputs sizes.

💡 Research Summary

The paper introduces a novel static‑analysis technique for bounding the memory consumption of object‑oriented (OO) programs by adapting the notion of sup‑interpretations, originally devised for first‑order functional languages. Sup‑interpretations assign to each function symbol a numeric expression that serves as an upper bound on the size of the value it computes. This tool has previously enabled characterisations of complexity classes such as AL𝑜𝑔TIME for functional programs. The authors’ goal is to transfer this powerful framework to a realistic fragment of OO languages while preserving its analytical strength.

Program model.
The authors define a restricted OO core that includes: (i) class constructors that encode natural numbers using algebraic data structures (e.g., binary trees, linked lists), (ii) non‑recursive methods, (iii) explicit loop and while constructs, and (iv) side effects limited to a set of global variables. Object fields are not directly mutable; instead, any state change is modelled as an update of a global variable. This design choice eliminates the need for a sophisticated alias analysis and makes the size of an object a well‑defined quantity (the number of constructor nodes it contains).

Sup‑interpretations for OO.
Each constructor and method is mapped to an integer polynomial. The polynomial bounds the size of the object produced by the corresponding operation as a function of the sizes of its arguments and of the current global state. To handle method calls, the authors introduce a size environment that records, for every program point, an upper bound on the size of each live object and each global variable. When a method is invoked, the size environment is updated by substituting the argument sizes into the method’s polynomial and by adding the effect of any global updates. This yields a compositional, global bound that can be propagated through arbitrary control‑flow graphs.

Brotherly criterion.
The central contribution is the brotherly criterion, a set of syntactic‑semantic conditions guaranteeing that the size environment remains polynomially bounded throughout execution. The criterion consists of two parts:

1. Loop‑bound condition. The number of iterations of any loop or while statement must be expressible as a polynomial in the sizes of the objects that control the loop (typically a counter object). This excludes unbounded loops whose iteration count depends on data that can grow super‑polynomially.

2. Operation‑bound condition. Every statement inside a method—constructor calls, global assignments, object returns—must be covered by the sup‑interpretation associated with the invoked symbol. In other words, the polynomial assigned to a statement must dominate the actual size increase caused by that statement.

If a program satisfies both conditions, the authors prove that for every execution the size of every object created during the run is bounded by a polynomial function of the sizes of the initial inputs. Such programs are termed brotherly programs.

Illustrative examples.
To demonstrate applicability, the paper presents two case studies.

Example 1: Integer calculator. A class Calc provides methods for addition, subtraction, multiplication, and division. Each operation creates a new integer object via a constructor that represents the result in unary form. The sup‑interpretations are linear polynomials (e.g., add(x,y) ≤ x + y). The only loop is a bounded repetition that processes a fixed list of commands, satisfying the loop‑bound condition. Consequently, the calculator is brotherly and its memory usage grows linearly with the size of the input numbers.

Example 2: List‑based merge sort. The program defines a List class with constructors nil and cons. The mergeSort method recursively splits a list and merges the sorted halves. Recursion is simulated by a bounded depth loop that iterates at most log₂ n times, where n is the length of the input list (the length is directly encoded by the number of cons nodes). The merge method’s sup‑interpretation is merge(x,y) ≤ x + y, reflecting that merging two lists yields a list whose size is the sum of the inputs. Both the loop‑bound and operation‑bound conditions hold, establishing that merge sort is brotherly and its auxiliary memory consumption is O(n log n), a polynomial bound.

Theoretical results.
The authors formalize the notion of a size environment as a mapping from program symbols to non‑negative integers and prove a soundness theorem: if a program satisfies the brotherly criterion, then for any reachable configuration the size environment provides a valid upper bound on the actual object sizes. The proof proceeds by structural induction on the program’s control‑flow graph, using the monotonicity of the assigned polynomials and the polynomial bound on loop iterations.

Limitations and future work.
The current framework deliberately excludes several common OO features: recursive methods, dynamic dispatch, multiple inheritance, and mutable fields. Extending sup‑interpretations to handle recursion would require a fixed‑point construction over polynomial spaces, while mutable fields would necessitate a more refined alias analysis to track per‑object size changes. Moreover, the treatment of side effects is confined to a global store; incorporating per‑object side effects (e.g., field updates) is identified as a promising direction. Finally, integrating the approach with existing static analysis tools (e.g., abstract interpretation frameworks) could automate the generation of sup‑interpretations for real‑world languages such as Java or C#.

Conclusion.
By transplanting sup‑interpretations into a carefully chosen OO fragment and introducing the brotherly criterion, the paper provides a rigorous method for guaranteeing that the size of objects produced by a program is polynomially bounded in the size of its inputs. This contribution bridges a gap between implicit computational complexity, traditionally focused on functional languages, and the practical needs of OO software engineering, opening avenues for static resource analysis, compiler optimisations, and complexity‑aware software design.