ACM Conference on Programming Language Design and Implementation (PLDI), June 2003 Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar Boyapati, Alexandru Salcianu,˘ William Beebee, Jr., Martin Rinard MIT Laboratory for Computer Science 200 Technology Square, Cambridge, MA 02139 {chandra,salcianu,wbeebee,rinard}@lcs.mit.edu Abstract Keywords The Real-Time Specification for Java (RTSJ) allows a pro- Ownership Types, Regions, Encapsulation, Real-Time gram to create real-time threads with hard real-time con- straints. Real-time threads use region-based memory man- agement to avoid unbounded pauses caused by interference 1. Introduction from the garbage collector. The RTSJ uses runtime checks The Real-Time Specification for Java (RTSJ) [8] provides to ensure that deleting a region does not create dangling ref- a framework for building real-time systems. The RTSJ al- erences and that real-time threads do not access references lows a program to create real-time threads with hard real- to objects allocated in the garbage-collected heap. This pa- time constraints. These real-time threads cannot use the per presents a static type system that guarantees that these garbage-collected heap because they cannot afford to be in- runtime checks will never fail for well-typed programs. Our terrupted for unbounded amounts of time by the garbage type system therefore 1) provides an important safety guar- collector. Instead, the RTSJ allows these threads to use ob- antee for real-time programs and 2) makes it possible to jects allocated in immortal memory (which is never garbage eliminate the runtime checks and their associated overhead. collected) or in regions [42]. Region-based memory manage- Our system also makes several contributions over previ- ment systems structure memory by grouping objects in re- ous work on region types. For object-oriented programs, it gions under program control. Memory is reclaimed by delet- combines the benefits of region types and ownership types ing regions, freeing all objects stored therein. The RTSJ in a unified type system framework. For multithreaded pro- uses runtime checks to ensure that deleting a region does grams, it allows long-lived threads to share objects without not create dangling references and that real-time threads do using the heap and without memory leaks. For real-time not access heap references. programs, it ensures that real-time threads do not interfere This paper presents a static type system for writing real- with the garbage collector. Our experience indicates that time programs in Java. Our system guarantees that the our type system is sufficiently expressive and requires lit- RTSJ runtime checks will never fail for well-typed programs. tle programming overhead, and that eliminating the RTSJ Our system thus serves as a front-end for the RTSJ platform. runtime checks using a static type system can significantly It offers two advantages to real-time programmers. First, it decrease the execution time of real-time programs. provides an important safety guarantee that a program will never fail because of a failed RTSJ runtime check. Second, it Categories and Subject Descriptors allows RTSJ implementations to remove the RTSJ runtime checks and eliminate the associated overhead. D.3.3 [Programming Languages]: Language Constructs; Our approach is applicable even outside the RTSJ context; D.2.4 [Software Engineering]: Program Verification; it could be adapted to provide safe region-based memory C.3 [Special-Purpose Systems]: Real-time Systems management for other real-time languages as well. General Terms Our system makes several important technical contribu- Languages, Verification, Theory tions over previous type systems for region-based memory management. For object-oriented programs, it combines re- This research was supported by DARPA/AFRL Contract F33615- gion types [16, 23, 34, 42] and ownership types [11, 12, 14, 00-C-1692, NSF Grant CCR00-86154, NSF Grant CCR00-73513, 18, 19] in a unified type system framework. Region types NSF Grant CCR02-09075, and the Singapore-MIT Alliance. statically ensure that programs never follow dangling refer- ences. Ownership types statically enforce object encapsula- tion and enable modular reasoning about program correct- ness in object-oriented programs. Permission to make digital or hard copies of all or part of this work for Consider, for example, a Stack object s that is imple- personal or classroom use is granted without fee provided that copies are mented using a Vector subobject v. To reason locally about not made or distributed for profit or commercial advantage and that copies the correctness of the Stack implementation, a programmer bear this notice and the full citation on the first page. To copy otherwise, to must know that v is not directly accessed by objects outside republish, to post on servers or to redistribute to lists, requires prior specific s. With ownership types, a programmer can declare that s permission and/or a fee. PLDI’03, June 9–11, 2003, San Diego, California, USA. owns v. The type system then statically ensures that v is Copyright 2003 ACM 1-58113-662-5/03/0006 ...$5.00. encapsulated within s. 324 In an object-oriented language that only has region types The unified ownership type system requires little program- (e.g., [16]), the types of s and v would declare that they are ming overhead, its typechecking is fast and scalable, and it allocated in some region r. In an object-oriented language provides several benefits. The unified ownership type system that only has ownership types, the type of v would declare thus offers a promising approach for making object-oriented that it is owned by s. Our type system provides a simple programs more reliable. unified mechanism to declare both properties. The type of s can declare that it is allocated in r and the type of v can Contributions declare that it is owned by s. Our system then statically To summarize, this paper makes the following contributions: ensures that both objects are allocated in r, that there are no pointers to v and s after r is deleted, and that v is en- • Region types for object-oriented programs: Our capsulated within s. Our system thus combines the benefits system combines region types and ownership types in a of region types and ownership types. unified type system framework that statically enforces object encapsulation as well as enables safe region- Our system extends region types to multithreaded pro- based memory management. grams by allowing explicit memory management for objects shared between threads. It allows threads to communicate • Region types for multithreaded programs: Our through objects in shared regions in addition to the heap. system introduces 1) subregions within a shared region, A shared region is deleted when all threads exit the region. so that long-lived threads can share objects without However, programs in a system with only shared regions using the heap and without memory leaks and 2) typed (e.g., [33]) will have memory leaks if two long-lived threads portal fields to serve as a starting point for typed inter- communicate by creating objects in a shared region. This thread communication. It also introduces user-defined is because the objects will not be deleted until both threads region kinds to support subregions and portals. exit the shared region. To solve this problem, we introduce • Region types for real-time programs: Our system the notion of subregions within a shared region. A subregion allows programs to create LT (Linear Time) and VT can be deleted more frequently, for example, after each loop (Variable Time) regions as in the RTSJ. It checks that iteration in the long-lived threads. real-time threads do not use heap references, create Our system also introduces typed portal fields in subre- new regions, or allocate objects in VT regions, so that gions to serve as a starting point for inter-thread communi- they do not wait for unbounded amounts of time. It cation. Portals also allow typed communication, so threads also prevents an RTSJ priority inversion problem. do not have to downcast from Object to more specific types. Our approach therefore avoids any dynamic type errors as- • Type inference: Our system uses a combination sociated with these downcasts. Our system introduces user- of intra-procedural type inference and well-chosen de- defined region kinds to support subregions and portal fields. faults to significantly reduce programming overhead. Our system extends region types to real-time programs Our approach permits separate compilation. by statically ensuring that real-time threads do not inter- • Experience: We have implemented several programs fere with the garbage collector. Our system augments re- in our system. Our experience indicates that our type gion kind declarations with region policy declarations. It system is sufficiently expressive and requires little pro- supports two policies for creating regions as in the RTSJ. A gramming overhead. We also ran the programs on our region can be an LT (Linear Time) region, or a VT (Vari- RTSJ platform [6, 7]. Our experiments show that elim- able Time) region. Memory for an LT region is preallocated inating the RTSJ runtime checks using a static type at region creation time, so allocating an object in an LT system can significantly speed-up programs. region only takes time proportional to the size of the object (because all the bytes have to be zeroed). Memory for a VT The paper is organized as follows. Section 2 describes our region is allocated on demand, so allocating an object in a type system. Section 3 describes our experimental results. VT region takes variable time. Our system checks that real- Section 4 presents related work. Section 5 concludes. time threads do not use heap references, create new regions, or allocate objects in VT regions.