Inference of reference immutability in Java

Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2008.This electronic version was submitted by the student author. The certified thesis is available in the Institute Archives and Special Collections.Includes bibliographical references (p. 81-83).Javari is an extension of Java that supports reference immutability constraints. Programmers write Javari type qualifiers, such as the readonly type qualifier, in their programs, and the Javari typechecker detects mutation errors (incorrect side effects) or verifies their absence. While case studies have demonstrated the practicality and value of Javari, a barrier to usability remains in the development process. A Javari program will not typecheck unless all the references in the APIs of libraries it uses are annotated with Javari type qualifiers. Manually converting existing Java libraries to Javari is both tedious and error-prone; the development process requires an automated solution. This thesis presents an algorithm for statically inferring reference immutability in Javari. The flow-insensitive and context-sensitive algorithm is sound and produces a set of qualifiers that typecheck in Javari. The algorithm is precise in that it infers the most readonly qualifiers possible; adding any additional readonly qualifiers will cause the program to not typecheck. A tool, Javarifier, implements this algorithm in order to infer the Javari type qualifiers over a set of class files. Javarifier can also insert these qualifiers into the corresponding source code, if the source code is available. Javarifier automatically converts Java libraries to Javari. Additionally, Javarifier eases the task of converting legacy programs to Javari by inferring the mutability of every reference in a program. In case studies, Javarifier correctly inferred mutability over Java programs of up to 110 KLOC.by Jaime QuinonezM.Eng

Conciliar Christology and the Consistency of Divine Immutability with a Mutable, Incarnate God

[paragraph 3 of the article] The goal of this article is to flesh out that initial understanding of incarnational immutability. The method I employ to attain this goal is to consider cases of predications from the texts of conciliar Christology. I show potential ontological truth conditions for those predications being true that do not require the truth conditions I propose for immutability to be unsatisfied. Put otherwise, I show ontological truth conditions for predications that imply Christ’s mutability and Incarnation that are also consistent with the truth of “Christ is immutable.” Since the truth conditions for the incarnational texts do not require the falsity of the claim that “Christ is immutable,” the incarnational claims do not require the rejection of immutability. In other words, the Incarnation is no reason to deny divine immutability, and vice versa

Definite Reference Mutability

Reference immutability type systems such as Javari and ReIm ensure that a given reference cannot be used to mutate the referenced object. These systems are conservative in the sense that a mutable reference may be mutable due to approximation. In this paper, we present ReM (for definite Re[ference] M[utability]). It separates mutable references into (1) definitely mutable, and (2) maybe mutable, i.e., references whose mutability is due to inherent approximation. In addition, we propose a CFL-reachability system for reference immutability, and prove that it is equivalent to ReIm/ReM, thus building a novel framework for reasoning about correctness of reference immutability type systems. We have implemented ReM and applied it on a large benchmark suite. Our results show that approximately 86.5% of all mutable references are definitely mutable

Pluggable type-checking for custom type qualifiers in Java

We have created a framework for adding custom type qualifiers to the Javalanguage in a backward-compatible way. The type system designer definesthe qualifiers and creates a compiler plug-in that enforces theirsemantics. Programmers can write the type qualifiers in their programs andbe informed of errors or assured that the program is free of those errors.The system builds on existing Java tools and APIs.In order to evaluate our framework, we have written four type-checkersusing the framework: for a non-null type system that can detect andprevent null pointer errors; for an interned type system that can detectand prevent equality-checking errors; for a reference immutability typesystem, Javari, that can detect and prevent mutation errors; and for areference and object immutability type system, IGJ, that can detect andprevent even more mutation errors. We have conducted case studies usingeach checker to find real errors in existing software. These case studiesdemonstrate that the checkers and the framework are practical and useful

Rational Epistemics of Divine Reality Leading to Monism

Rational epistemics is the line of reasoning inclined to reason separated from reliance on experience that ultimately leads to monism or non-dualism

C++ const and Immutability: An Empirical Study of Writes-Through-const

The ability to specify immutability in a programming language is a powerful tool for developers, enabling them to better understand and more safely transform their code without fearing unintended changes to program state. The C++ programming language allows developers to specify a form of immutability using the const keyword. In this work, we characterize the meaning of the C++ const qualifier and present the ConstSanitizer tool, which dynamically verifies a stricter form of immutability than that defined in C++: it identifies const uses that are either not consistent with transitive immutability, that write to mutable fields, or that write to formerly-const objects whose const-ness has been cast away. We evaluate a set of 7 C++ benchmark programs to find writes-through-const, establish root causes for how they fail to respect our stricter definition of immutability, and assign attributes to each write (namely: synchronized, not visible, buffer/cache, delayed initialization, and incorrect). ConstSanitizer finds 17 archetypes for writes in these programs which do not respect our version of immutability. Over half of these seem unnecessary to us. Our classification and observations of behaviour in practice contribute to the understanding of a widely-used C++ language feature

A Syntactic Model of Mutation and Aliasing

Traditionally, semantic models of imperative languages use an auxiliary structure which mimics memory. In this way, ownership and other encapsulation properties need to be reconstructed from the graph structure of such global memory. We present an alternative "syntactic" model where memory is encoded as part of the program rather than as a separate resource. This means that execution can be modelled by just rewriting source code terms, as in semantic models for functional programs. Formally, this is achieved by the block construct, introducing local variable declarations, which play the role of memory when their initializing expressions have been evaluated. In this way, we obtain a language semantics which directly represents at the syntactic level constraints on aliasing, allowing simpler reasoning about related properties. To illustrate this advantage, we consider the issue, widely studied in the literature, of characterizing an isolated portion of memory, which cannot be reached through external references. In the syntactic model, closed block values, called "capsules", provide a simple representation of isolated portions of memory, and capsules can be safely moved to another location in the memory, without introducing sharing, by means of "affine' variables. We prove that the syntactic model can be encoded in the conventional one, hence efficiently implemented.Comment: In Proceedings DCM 2018 and ITRS 2018 , arXiv:1904.0956

Designing with Static Capabilities and Effects: Use, Mention, and Invariants (Pearl)

Capabilities (whether object or reference capabilities) are fundamentally tools to restrict effects. Thus static capabilities (object or reference) and effect systems take different technical machinery to the same core problem of statically restricting or reasoning about effects in programs. Any time two approaches can in principle address the same sets of problems, it becomes important to understand the trade-offs between the approaches, how these trade-offs might interact with the problem at hand. Experts who have worked in these areas tend to find the trade-offs somewhat obvious, having considered them in context before. However, this kind of design discussion is often written down only implicitly as comparison between two approaches for a specific program reasoning problem, rather than as a discussion of general trade-offs between general classes of techniques. As a result, it is not uncommon to set out to solve a problem with one technique, only to find the other better-suited. We discuss the trade-offs between static capabilities (specifically reference capabilities) and effect systems, articulating the challenges each approach tends to have in isolation, and how these are sometimes mitigated. We also put our discussion in context, by appealing to examples of how these trade-offs were considered in the course of developing prior systems in the area. Along the way, we highlight how seemingly-minor aspects of type systems - weakening/framing and the mere existence of type contexts - play a subtle role in the efficacy of these systems