• Documents
  • Authors
  • Tables
  • Other Seers ▼
    RefSeer AckSeer CollabSeer SeerSeer
  • Log in
  • Sign up
  • MetaCart

CiteSeerX logo

Advanced Search Include Citations
Advanced Search Include Citations | Disambiguate

MM garbage collector for C (1989)

by Thomas Wang
Add To MetaCart

Tools

Sorted by:
Results 1 - 10 of 28
Next 10 →

Foundational Proof-Carrying Code

by Andrew W. Appel , 2001
"... Proof-carrying code is a framework for the mechanical verification of safety properties of machine language programs, but the problem arises of quis custodiat ipsos custodes---who will verify the verifier itself? Foundational proof-carrying code is verification from the smallest possible set of axio ..."
Abstract - Cited by 213 (9 self) - Add to MetaCart
Proof-carrying code is a framework for the mechanical verification of safety properties of machine language programs, but the problem arises of quis custodiat ipsos custodes---who will verify the verifier itself? Foundational proof-carrying code is verification from the smallest possible set of axioms, using the simplest possible verifier and the smallest possible runtime system. I will describe many of the mathematical and engineering problems to be solved in the construction of a foundational proof-carrying code system.

Region-Based Memory Management in Cyclone

by Dan Grossman , Greg Morrisett, Trevor Jim, Michael Hicks, Yanling Wang, James Cheney - IN PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION (PLDI'02) , 2002
"... Cyclone is a type-safe programming language derived from C. The primary design goal of Cyclone is to let programmers control data representation and memory management without sacrificing type-safety. In this paper, we focus on the region-based memory management of Cyclone and its static typing disci ..."
Abstract - Cited by 163 (13 self) - Add to MetaCart
Cyclone is a type-safe programming language derived from C. The primary design goal of Cyclone is to let programmers control data representation and memory management without sacrificing type-safety. In this paper, we focus on the region-based memory management of Cyclone and its static typing discipline. The design incorporates several advancements, including support for region subtyping and a coherent integration with stack allocation and a garbage collector. To support separate compilation, Cyclone requires programmers to write some explicit region annotations, but a combination of default annotations, local type inference, and a novel treatment of region e#ects reduces this burden. As a result, we integrate C idioms in a region-based framework. In our experience, porting legacy C to Cyclone has required altering about 8% of the code; of the changes, only 6% (of the 8%) were region annotations.

A Linearly Typed Assembly Language

by James Cheney, Greg Morrisett - In Workshop on Types in Compilation
"... Today's type-safe low-level languages rely on garbage collection to recycle heap-allocated objects safely. We present LTAL, a safe, low-level, yet simple language that "stands on its own": it guarantees safe execution within a fixed memory space, without relying on external run-time support. We demo ..."
Abstract - Cited by 136 (35 self) - Add to MetaCart
Today's type-safe low-level languages rely on garbage collection to recycle heap-allocated objects safely. We present LTAL, a safe, low-level, yet simple language that "stands on its own": it guarantees safe execution within a fixed memory space, without relying on external run-time support. We demonstrate the expressiveness of LTAL by giving a type-preserving compiler for the functional core of ML. But this independence comes at a steep price: LTAL's type system imposes a draconian discipline of linearity that ensures that memory can be reused safely, but prohibits any useful kind of sharing. We present the results of experiments with a prototype LTAL system that show just how high the price of linearity can be.

Object Ownership and Containment

by David Clarke , 2001
"... Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of t ..."
Abstract - Cited by 112 (17 self) - Add to MetaCart
Object-oriented programming relies on inter-object aliases to implement data structures and other abstractions. Objects have mutable state, but it is when mutable state interacts with aliasing that problems arise. Through aliasing an object's state can be changed without the object being aware of the changes, potentially violating the object's invariants. This problem is fundamentally unresolvable. Many idioms such as the Observer design pattern rely on it. Hence aliasing cannot be eliminated from object-oriented programming, it can only be managed. Various proposals have appeared in the literature addressing the issue of alias management. The most promising are based on alias encapsulation, which limits access to objects to within certain well-defined boundaries. Our approach called ownership types falls into this category. An object can specify the objects it owns, called its representation, and which objects can access its representation. A type system protects the representation by enforcing a well-defined containment invariant. Our approach is a formal one. Ownership types are cast as a type system using an minor extension to Abadi and Cardelli's object calculus with subtyping. With this formalisation we prove the soundness of our ownership types system and demonstrate that well-typed programs satisfy the containment invariant. In addition, we also provide a firm grounding to enable ownership types to be safely added to an objectoriented programming language with inheritance, subtyping, and nested classes, as well as offering a sound basis for future work. Our type system can model aggregate objects with multiple interface objects sharing representation and friendly functions which access multiple objects' private representations, among other examples, thus over...

Defunctionalization at Work

by Olivier Danvy, Lasse R. Nielsen , 2001
"... ..."
Abstract - Cited by 59 (34 self) - Add to MetaCart
Abstract not found

Local Reasoning about a Copying Garbage Collector

by Lars Birkedal, Noah Torp-smith, John C. Reynolds - In 31st ACM POPL , 2004
"... We present a programming language, model, and logic appropriate for implementing and reasoning about a memory management system. We then state what is meant by correctness of a copying garbage collector, and employ a variant of the novel separation logics [18, 23] to formally specify partial correct ..."
Abstract - Cited by 58 (7 self) - Add to MetaCart
We present a programming language, model, and logic appropriate for implementing and reasoning about a memory management system. We then state what is meant by correctness of a copying garbage collector, and employ a variant of the novel separation logics [18, 23] to formally specify partial correctness of Cheney's copying garbage collector [8]. Finally, we prove that our implementation of Cheney's algorithm meets its specification, using the logic we have given, and auxiliary variables [19].

Checking and Inferring Local Non-Aliasing

by Alex Aiken, John Kodumal, Jeffrey S. Foster, Tachio Terauchi , 2003
"... In prior work [15] we studied a language construct restrict that allows programmers to specify that certain pointers are not aliased to other pointers used within a lexical scope. Among other applications, programming with these constructs helps program analysis tools locally recover strong updates, ..."
Abstract - Cited by 40 (9 self) - Add to MetaCart
In prior work [15] we studied a language construct restrict that allows programmers to specify that certain pointers are not aliased to other pointers used within a lexical scope. Among other applications, programming with these constructs helps program analysis tools locally recover strong updates, which can improve the tracking of state in flow-sensitive analyses. In this paper we continue the study of restrict and introduce the construct confine. We present a type and effect system for checking the correctness of these annotations, and we develop efficient constraint-based algorithms implementing these type checking systems. To make it easier to use restrict and confine in practice, we show how to automatically infer such annotations without programmer assistance. In experiments on locking in 589 Linux device drivers, confine inference can automatically recover strong updates to eliminate 95% of the type errors resulting from weak updates.

Non-Compacting Memory Allocation and Real-Time Garbage Collection

by Mark S. Johnstone, Advisor Paul, R. Wilson , 1996
"... Garbage collection is the automatic reclamation of computer storage [Knu73, Coh81, Wil92, Wil95]. While in many systems, programmers must explicitly reclaim heap memory at some point in their program by using a "free" or "dispose" statement, garbage collected systems free the programmer from this ..."
Abstract - Cited by 26 (2 self) - Add to MetaCart
Garbage collection is the automatic reclamation of computer storage [Knu73, Coh81, Wil92, Wil95]. While in many systems, programmers must explicitly reclaim heap memory at some point in their program by using a "free" or "dispose" statement, garbage collected systems free the programmer from this burden. In spite of its obvious attractiveness for many applications, garbage collection for real-time programs is not popular. This is largely due to the perceived cost and disruptiveness of garbage collection in general, and of incremental garbage collection in particular. Most existing "real-time" garbage collectors are not in fact usefully real-time, largely due to the use of a read barrier to trigger incremental copying of data structures being traversed by the running application. This may slow down running applications unpredictably, even though individual increments of garbage collection work are small and bounded. We have developed a hard real-time garbage collector which us...

Experience with safe manual memory-management in cyclone

by Michael Hicks, Greg Morrisett, Dan Grossman, Trevor Jim - In Proc. of the 4th international symposium on Memory management (ISMM , 2004
"... The goal of the Cyclone project is to investigate type safety for low-level languages such as C. Our hardest challenge has been providing programmers control over memory management while retaining type safety. This paper reports on our experience trying to integrate and effectively use two previousl ..."
Abstract - Cited by 26 (7 self) - Add to MetaCart
The goal of the Cyclone project is to investigate type safety for low-level languages such as C. Our hardest challenge has been providing programmers control over memory management while retaining type safety. This paper reports on our experience trying to integrate and effectively use two previously proposed, type-safe memory management mechanisms: statically-scoped regions and unique pointers. We found that these typing mechanisms can be combined to build alternative memory-management abstractions, such as reference counted objects and arenas with dynamic lifetimes, and thus provide a flexible basis. Our experience—porting C code and building new applications for resource-constrained systems—confirms that experts can use these features to improve memory footprint and sometimes to improve throughput when used instead of, or in combination with, a conservative garbage collector. 1

Safe and flexible memory management in Cyclone

by Michael Hicks, Greg Morrisett, Dan Grossman, Trevor Jim , 2003
"... Cyclone is a type-safe programming language intended for applications requiring control over memory management. Our previous work on Cyclone included support for stack allocation, lexical region allocation, and a garbage-collected heap. We achieved safety (i.e., prevented dangling pointers) through ..."
Abstract - Cited by 14 (2 self) - Add to MetaCart
Cyclone is a type-safe programming language intended for applications requiring control over memory management. Our previous work on Cyclone included support for stack allocation, lexical region allocation, and a garbage-collected heap. We achieved safety (i.e., prevented dangling pointers) through a region-based type-and-effects system. This paper describes some new memory-management mechanisms that we have integrated into Cyclone: dynamic regions, unique pointers, and reference-counted objects. Our experience shows that these new mechanisms are well suited for the timely recovery of objects in situations where it is awkward to use lexical regions. Crucially, programmers can write reusable functions without unnecessarily restricting callers’ choices among the plethora of memory-management options. To achieve this goal, Cyclone employs a combination of polymorphism and scoped constructs that temporarily let us treat objects as if they were allocated in a lexical region. 1.
The National Science Foundation
  • About CiteSeerX
  • Submit Documents
  • Privacy Policy
  • Help
  • Data
  • Source
  • Contact Us

Developed at and hosted by The College of Information Sciences and Technology

© 2007-2010 The Pennsylvania State University