A practical type system and language for reference immutability

Abstract

This paper describes a type system that is capable of expressing and enforcing immutability constraints. The specific constraint expressed is that the abstract state of the object to which an immutable reference refers cannot be modified using that reference. The abstract state is (part of) the transitively reachable state: that is, the state of the object and all state reachable from it by following references. The type system permits explicitly excluding fields or objects from the abstract state of an object. For a statically type-safe language, the type system guarantees reference immutability. If the language is extended with immutability downcasts, then run-time checks enforce the reference immutability constraints.In order to better understand the usability and efficacy of the type system, we have implemented an extension to Java, called Javari, that includes all the features of our type system. Javari is interoperable with Java and existing JVMs. It can be viewed as a proposal for the semantics of the Java const keyword, though Javari's syntax uses readonly instead. This paper describes the design and implementation of Javari, including the type-checking rules for the language. This paper also discusses experience with 160,000 lines of Javari code. Javari was easy to use and provided a number of benefits, including detecting errors in well-tested code.

Combined static and dynamic mutability analysis

“…As with previous work [22,3,18,4], our immutability definition excludes aliasing-on top-level entry to a method, all parameters are considered to be fully un-aliased (i.e., point to disjoint parts of the heap). Accounting for all possible side effects under all possible aliasing conditions would yield unusably conservative results.…”

Inference of Reference Immutability

“…Finally, a reference is declared polyread if the mutable context's constraint variable is in the constraint set but the readonly constraint variable is not in the constraint set, because the mutability of the reference depends on which version of the method is called. 6 Thus, in the example of Figure 3, after the constraints have been solved, the receiver of getSeat() is known to be mutable in a mutable context but not known to be mutable in a readonly context, so it is annotated as polyread. The reference returned by getSeat() is similarly known to be mutable in a mutable context but not known to be mutable in a readonly context, so it is also annotated as polyread.…”

“…We briefly mention type checkers for closely related notions of reference immutability. Birka built a type-checker for an earlier dialect of Javari that lacked support for Java generics, and wrote 160,000 lines of code in Javari [6]. Correa later wrote a complete Javari implementation using the Checker Framework [20] and did case studies involving 13,000 lines of Javari [19].…”

Handles: Behavior-propagating first class references for dynamically-typed languages

“…For example, using a static type system, Birka et al add a read-only type qualifier, which ensures that all state that is transitively reachable from a read-only reference is also read-only [BE04]. Dynamically-typed languages do not provide static type information, seriously compromising any static analysis at compile time.…”

“…Hakonen et al [HLR + 99] propose the concept of deeply immutable references; they only discuss possible implementation strategies without presenting a working implementation. In Javari, Birka et al [BE04] extend Java with a static type system of transitively read-only references. These works are the most similar to our read-only references; the main difference is that they are proposed for statically typed languages.…”