Comprehending Annotations on Object-Oriented Programs using Fractional Permissions John Boyland University of Wisconsin-Milwaukee, USA boyland@cs.uwm.edu William Retert University of Wisconsin-Milwaukee, USA williamr@cs.uwm.edu Yang Zhao Nanjing University of Science and Technology, China yangzhao@cs.njust.edu.cn ABSTRACT Fractional permissions are a general system for managing access to mutable state. We show how fractional permis- sions can give semantics to a regimen of annotations includ- ing“unique,”“non-null,”“read-only,” ownership, and method effects. The unification supports new annotations: “unique- write” and “from”. We also develop a model of object in- variants in the presence of inheritance using “nesting,” an extension of “adoption.” 1. INTRODUCTION Imperative object-oriented programming is a powerful and flexible system of programming, but imperative features can make programs harder to understand and reason about, and thus harder to optimize. Interactions between parts of the program can be hard to track because of aliasing, in which the same mutable state can be accessed with different names. The additional possibility that any reference may be null means that almost any operation could potentially throw a null pointer exception. Furthermore, initialization through constructors may include arbitrary code which, combined with dynamic dispatch, can lead to a method being called on an object which has not been fully initialized. All these prob- lems can occur in single-threaded programs; adding multi- threading brings a host of new problems. Many researchers propose a solution to these problems us- ing annotations. Rather than design a new language (and thus a new compiler and run-time system), they instead use annotations on code elements to indicate the design intent of the code. These annotations have a dual function: they describe the behavior of the code for better understanding by users; they prescribe the behavior of the code for im- plementers and program maintainers. We are interested in purely non-executable annotations in which the behavior of the code is entirely unaffected by the annotations. Annota- tions can be seen as an optional type system [18]; the ad- vantage is that annotations can be checked separately from the main compiler and runtime system. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWACO ’09, July 6 2009, Genova, Italy Copyright 2009 ACM 978-1-60558-546-8/09/07 ...$10.00. The host of (mainly non-executable) annotations that have been proposed to describe design intent in object-oriented programs includes borrowed [15] (also called lent [3, 2]), data groups [34] (also called regions [19, 29]), effects [29, 20], immutability [43, 6], non-nullness [27], ownership [24, 23, 2, 9], raw [27], readonly [40, 32, 47, 6, 50], and unique [31, 11, 38, 2, 22]. While most of the concepts involved are fairly intuitive, the precise semantics for something as “obvious” as unique can be difficult to pin down [11]. Moreover, putting all these annotations together can lead to a semantic muddle as each proposal uses its own notation and semantics. Even so, combining annotations would be straightforward if the annotations did not interact with one another. Un- fortunately, the interactions of individually-defined annota- tions are not immediately obvious, as we have shown for AliasJava [2] with the interaction between uniqueness and borrowing [16]. The undesired interaction in this case (rep- resentation exposure) can be addressed by annotating meth- ods with field effects, which adds another annotation with which to interact. Similarly, Leino and others [37] found that an “ownership exclusion” principle was needed in or- der to maintain object invariants. When considering effects, access to immutable state can be ignored, but access to read- only state cannot be, since that access may interfere with a writer. Likewise, effects through a unique reference may be mapped back to the holder of that reference. All annota- tions that describe access to mutable state; must interact on some level. This paper addresses the problem of annotation interac- tion by providing a foundation on which to ground all the annotations described above. Fractional permissions can be used to give a precise meaning to each annotation, and can be checked statically and modularly (one method body at a time). We have already shown [16] how uniqueness and object-oriented effects systems can be modeled using per- missions. In this paper, we further add ownership, non-null, read-only, and immutable type qualifiers. Along the way, we show how to model “unary” object invariants (invariants that refer only to one field). Furthermore, (but this is not explored in this paper), fractional permissions can be used to express design intent annotations on multi-threaded pro- grams as well [51]. The theory of (fractional) permissions gets back to the basic issue: mutable state. In the object-oriented paradigm, fields of objects serve as loci of mutable state. Each field is associated with exactly one permission. A single permission can be broken into “fractions” each of which permits read access; write access requires the whole permission (possibly