Distilling the Real Cost of Production Garbage Collectors

Abridged abstract: despite the long history of garbage collection (GC) and its prevalence in modern programming languages, there is surprisingly little clarity about its true cost. Without understanding their cost, crucial tradeoffs made by garbage collectors (GCs) go unnoticed. This can lead to misguided design constraints and evaluation criteria used by GC researchers and users, hindering the development of high-performance, low-cost GCs. In this paper, we develop a methodology that allows us to empirically estimate the cost of GC for any given set of metrics. By distilling out the explicitly identifiable GC cost, we estimate the intrinsic application execution cost using different GCs. The minimum distilled cost forms a baseline. Subtracting this baseline from the total execution costs, we can then place an empirical lower bound on the absolute costs of different GCs. Using this methodology, we study five production GCs in OpenJDK 17, a high-performance Java runtime. We measure the cost of these collectors, and expose their respective key performance tradeoffs. We find that with a modestly sized heap, production GCs incur substantial overheads across a diverse suite of modern benchmarks, spending at least 7-82% more wall-clock time and 6-92% more CPU cycles relative to the baseline cost. We show that these costs can be masked by concurrency and generous provisioning of memory/compute. In addition, we find that newer low-pause GCs are significantly more expensive than older GCs, and, surprisingly, sometimes deliver worse application latency than stop-the-world GCs. Our findings reaffirm that GC is by no means a solved problem and that a low-cost, low-latency GC remains elusive. We recommend adopting the distillation methodology together with a wider range of cost metrics for future GC evaluations.Comment: Camera-ready versio

Latte: Lightweight Aliasing Tracking for Java

Many existing systems track aliasing and uniqueness, each with their own trade-off between expressiveness and developer effort. We propose Latte, a new approach that aims to minimize both the amount of annotations and the complexity of invariants necessary for reasoning about aliasing in an object-oriented language with mutation. Our approach only requires annotations for parameters and fields, while annotations for local variables are inferred. Furthermore, it relaxes uniqueness to allow aliasing among local variables, as long as this aliasing can be precisely determined. This enables support for destructive reads without changes to the language or its run-time semantics. Despite this simplicity, we show how this design can still be used for tracking uniqueness and aliasing in a local sequential setting, with practical applications, such as modeling a stack

a(MDÆ)2: A Model Driven Approach to Multi-Dimensional Separation of Concerns with OCL

AbstractA typical activity in the object-oriented software engineering process involves the construction of a class structure in terms of which the system behaviour is to be specified. The behaviour, however, commonly consists of multiple tasks, each of which usually needs only part of the information available in that class structure. Additionally, a different representation of the required information may be appropriate. Therefore, it would be useful to be able to have multiple views on the global class structure, each being suitable for the specification of the behaviour related to a certain task. This paper introduces a(MDÆ)2, a technique to realise such a strategy. It incorporates OCL as a powerful query language and advocates a model driven development process which relieves the developer from the burden of manually writing a considerable amount of tedious and error-prone code

Partial type constructors: Or, making ad hoc datatypes less ad hoc

This work is licensed under a Creative Commons Attribution 4.0 International License.Functional programming languages assume that type constructors are total. Yet functional programmers know better: counterexamples range from container types that make limiting assumptions about their contents (e.g., requiring computable equality or ordering functions) to type families with defining equations only over certain choices of arguments. We present a language design and formal theory of partial type constructors, capturing the domains of type constructors using qualified types. Our design is both simple and expressive: we support partial datatypes as first-class citizens (including as instances of parametric abstractions, such as the Haskell Functor and Monad classes), and show a simple type elaboration algorithm that avoids placing undue annotation burden on programmers. We show that our type system rejects ill-defined types and can be compiled to a semantic model based on System F. Finally, we have conducted an experimental analysis of a body of Haskell code, using a proof-of-concept implementation of our system; while there are cases where our system requires additional annotations, these cases are rarely encountered in practical Haskell code

Panorama - a software maintenance tool

Much of the effort in software maintenance is spent on finding relevant information and on program comprehension. Of the several challenges encountered during this process, some are: a) inadequate documentation, b) the developer doing the maintenance activity may not be the one who actually developed it and may be unfamiliar with the application domain (in addition to the unfamiliar code), c) information overload, and d) the relevant code may be scattered across multiple files of different types making it harder to find. Existing documentation in the form of Javadoc is inadequate in providing a global view of the working of the software. Panorama, a java based Eclipse plug-in, was developed to facilitate maintenance activities by providing mechanisms to document and to view expert knowledge and relevant code in the form of a concern. Some features of Panorama are: a code tracing feature that allows the expert to quickly find (so he can document it) lines of code executed in carrying out a function, a concern management feature that allows the expert to create and organize concern information in a hierarchical manner, a concern visualization and context management feature that helps the maintainer to handle information overload by allowing him to switch between contexts, an enhanced user-interface that helps the maintainer to easily navigate between relevant contexts and codes. Panorama also provides a Javadoc -like documentation of cross-cutting concerns that supplement existing Javadoc documentation to provide comprehensive information about the software. In a case study done to validate the usefulness of our tool, Panorama was used to document the SAVER software (a VB.NET based fairly large GIS software with 26,704 executable lines of code that is being actively used by the Iowa Department of Transportation to analyze automobile crashes over a period of time). SAVER has been undergoing continual bug-fixes and enhancement activities - and preliminary studies indicate that the supplementary documentation provided by Panorama has proven beneficial

Reference Capabilities for Flexible Memory Management: Extended Version

Verona is a concurrent object-oriented programming language that organises all the objects in a program into a forest of isolated regions. Memory is managed locally for each region, so programmers can control a program's memory use by adjusting objects' partition into regions, and by setting each region's memory management strategy. A thread can only mutate (allocate, deallocate) objects within one active region -- its "window of mutability". Memory management costs are localised to the active region, ensuring overheads can be predicted and controlled. Moving the mutability window between regions is explicit, so code can be executed wherever it is required, yet programs remain in control of memory use. An ownership type system based on reference capabilities enforces region isolation, controlling aliasing within and between regions, yet supporting objects moving between regions and threads. Data accesses never need expensive atomic operations, and are always thread-safe.Comment: 87 pages, 10 figures, 5 listings, 4 tables. Extended version of paper to be published at OOPSLA 202

SHIM: A Deterministic Approach to Programming with Threads

Concurrent programming languages should be a good fit for embedded systems because they match the intrinsic parallelism of their architectures and environments. Unfortunately, most concurrent programming formalisms are prone to races and nondeterminism, despite the presence of mechanisms such as monitors. In this paper, we propose SHIM, the core of a concurrent language with disciplined shared variables that remains deterministic, meaning the behavior of a program is independent of the scheduling of concurrent operations. SHIM does not sacrifice power or flexibility to achieve this determinism. It supports both synchronous and asynchronous paradigms---loosely and tightly synchronized threads---the dynamic creation of threads and shared variables, recursive procedures, and exceptions. We illustrate our programming model with examples including breadth-first-search algorithms and pipelines. By construction, they are race-free. We provide the formal semantics of SHIM and a preliminary implementation

A Grounded Conceptual Model for Ownership Types in Rust

Programmers learning Rust struggle to understand ownership types, Rust's core mechanism for ensuring memory safety without garbage collection. This paper describes our attempt to systematically design a pedagogy for ownership types. First, we studied Rust developers' misconceptions of ownership to create the Ownership Inventory, a new instrument for measuring a person's knowledge of ownership. We found that Rust learners could not connect Rust's static and dynamic semantics, such as determining why an ill-typed program would (or would not) exhibit undefined behavior. Second, we created a conceptual model of Rust's semantics that explains borrow checking in terms of flow-sensitive permissions on paths into memory. Third, we implemented a Rust compiler plugin that visualizes programs under the model. Fourth, we integrated the permissions model and visualizations into a broader pedagogy of ownership by writing a new ownership chapter for The Rust Programming Language, a popular Rust textbook. Fifth, we evaluated an initial deployment of our pedagogy against the original version, using reader responses to the Ownership Inventory as a point of comparison. Thus far, the new pedagogy has improved learner scores on the Ownership Inventory by an average of 9% ($N = 342, d = 0.56$).Comment: Published at OOPSLA 202