Dynamic Storage Management Research Articles

Efficient detection of all pointer and array access errors

We present a pointer and array access checking technique that provides complete error coverage through a simple set of program transformations. Our technique, based on an extended safe pointer representation, has a number of novel aspects. Foremost, it is the first technique that detects all spatial and temporal access errors. Its use is not limited by the expressiveness of the language; that is, it can be applied successfully to compiled or interpreted languages with subscripted and mutable pointers, local references, and explicit and typeless dynamic storage management, e.g., C. Because it is a source level transformation, it is amenable to both compile- and run-time optimization. Finally, its performance, even without compile-time optimization, is quite good. We implemented a prototype translator for the C language and analyzed the checking overheads of six non-trivial, pointer intensive programs. Execution overheads range from 130% to 540%; with text and data size overheads typically below 100%.

The measured cost of conservative garbage collection

AbstractBecause dynamic memory management is an important part of a large class of computer programs, high‐performance algorithms for dynamic memory management have been, and will continue to be, of considerable interest. Experience indicates that for many programs, dynamic storage allocation is so important that programmers feel compelled to write and use their own domain‐specific allocators to avoid the overhead of system libraries. As an alternative to explicit storage management techniques, conservative garbage collection has been suggested as an important algorithm for dynamic storage management in C programs. In this paper, I evaluate the costs of different dynamic storage management algorithms, including domain‐specific allocators, widely‐used general‐purpose allocators, and a publicly available conservative garbage collection algorithm. Surprisingly, I find that programmer enhancements often have little effect on program performance. I also find that the true cost of conservative garbage collection is not the CPU overhead, but the memory system overhead of the algorithm. I conclude that conservative garbage collection is a promising alternative to explicit storage management and that the performance of conservative collection is likely to improve in the future. C programmers should now seriously consider using conservative garbage collection instead of explicitly calling free in programs they write.

Mayfly: A general-purpose, scalable, parallel processing architecture

TheMayfly is a scalable general-purpose parallel processing system being designed at HP Laboratories, in collaboration with colleagues at the University of Utah. The system is intended to efficiently support parallel variants of modern programming languages such as Lisp, Prolog, and Object Oriented Programming models. These languages impose a common requirement on the hardware platform to supportdynamic system needs such as runtime type checking and dynamic storage management. The main programming language for the Mayfly is a concurrent dialect of Scheme. The system is based on a distributed-memory model, and communication between processing elements is supported by message passing. The initial prototype of Mayfly will consist of 19 identical processing elements interconnected in a hexagonal mesh structure. In order to achieve the goal of scalable performance, each processing element is a parallel processor as well, which permits the application code, runtime operating system, and communication to all run in parallel. A 7 processing element subset of the prototype is presently operational. This paper describes the hardware architecture after a brief background synopsis of the software system structure.

Multiprocessor execution of functional programs

Functional languages have recently gained attention as vehicles for programming in a concise and elegant manner. In addition, it has been suggested that functional programming provides a natural methodology for programming multiprocessor computers. This dissertation demonstrates that multiprocessor execution of functional programs is feasible, and results in a significant reduction in their execution times. Two implementations of the functional language ALFL were built on commercially available multiprocessors. Alfalfa is an implementation on the Intel iPSC hypercube multiprocessor, and Buckwheat is an implementation on the Encore Multimax shared-memory multiprocessor. Each implementation includes a compiler that performs automatic decomposition of ALFL programs. The compiler is responsible for detecting the inherent parallelism in a program, and decomposing the program into a collection of tasks, called serial combinators, that can be executed in parallel. One of the primary goals of the compiler is to generate serial combinators exhibiting the coarsest granularity possibly without sacrificing useful parallelism. This dissertation describes the algorithms used by the compiler to analyze, decompose, and optimize functional programs. The abstract machine model supported by Alfalfa and Buckwheat is called heterogeneous graph reduction, which is a hybrid of graph reduction and conventional stack-oriented execution. This model supports parallelism, lazy evaluation, and higher order functions while at the same time making efficient use of the processors in the system. The Alfalfa and Buckwheat run-time systems support dynamic load balancing, interprocessor communication (if required), and storage management. A large number of experiments were performed on Alfalfa and Buckwheat for a variety of programs. The results of these experiments, as well as the conclusions drawn from them, are presented.

Problems with the language modula‐2

AbstractOne of the first tasks of the working groups producing a Modula‐2 standard has been to identify problems with the language defined by N. Wirth. This paper reports on the major problems with the language. These occur in the areas of type coercions and casts, scope, strings, the module SYSTEM, dynamic storage management and opaque types. Some familiarity with the language Modula‐2 is assumed.

Optical Representations For Symbolic Logic

Artificial intelligence problems are solved on electronic computers by techniques that make heavy use of address calculation and dynamic management of data storage space. Optical computing, on the other hand, is normally associated with numerical problems in which the size of the data space is fixed and addressing may be handled in a predictable manner not affected by actual data values. In this paper we categorize expert system problems by the amount of dynamic storage management required and discuss several methods for eliminating unnecessary address manipulation by careful choice of data representation. Major emphasis is placed on the implementation of the mathematical technique of resolution. Various resolution strategies are analyzed, and the effect of these strategies on storage management is assessed with a view to minimizing the complexity of processing. Finally, electro-optical implementations are considered for the major functional elements of an optical resolution system.

Microprogrammable processor for object-oriented architecture

An advanced microprocessor has been developed for the high performance execution of object oriented language programs. In object oriented languages, improvement of frequent or complex operations such as dynamic type checking, procedure calls, and storage management, contributes toward the increase of overall performance. In order to improve their performance, the microprocessor adopts large on-chip register files, a large EPROM for microstore, and ingenious instruction dispatching and tag-handling mechanisms. By specially treating frequently accessed data, i.e., allocating activation records in register files, much of the data traffic can be effectively localized within the chip, and the complexity of procedure calls as well as the burden imposed on storage management can be alleviated. The tag-handling mechanisms efficiently perform dynamic type checking. As the result, the microprocessor, together with an efficient microprogram, executes object oriented language programs much faster than existing computers. Furthermore, it can efficiently execute other high-level languages by using corresponding microprograms, especially AI-languages.

Hardware/software cooperation in the iAPX-432

The Intel iAPX-432 is an object-based microcomputer system with a unified approach to the design and use of its architecture, operating system, and primary programming language. The concrete architecture of the 432 incorporates hardware support for data abstraction, small protection domains, and language-oriented run-time environments. It also uses its object-orientation to provide hardware support for dynamic heap storage management, interprocess communication, and processor dispatching. We begin with an overview of the 432 architecture so readers unfamiliar with its basic concepts will be able to follow the succeeding discussion without the need to consult the references. Following that, we introduce the various forms of hardware/software cooperation and the criteria by which a function or service is selected for migration. This is followed by several of the more interesting examples of hardware/software cooperation in the 432. A comparison of cooperation in the 432 with several contemporary machines and discussions of development issues, past and future, complete the paper.

Hardware/software cooperation in the iAPX-432

The Intel iAPX-432 is an object-based microcomputer system with a unified approach to the design and use of its architecture, operating system, and primary programming language. The concrete architecture of the 432 incorporates hardware support for data abstraction, small protection domains, and language-oriented run-time environments. It also uses its object-orientation to provide hardware support for dynamic heap storage management, interprocess communication, and processor dispatching. We begin with an overview of the 432 architecture so readers unfamiliar with its basic concepts will be able to follow the succeeding discussion without the need to consult the references. Following that, we introduce the various forms of hardware/software cooperation and the criteria by which a function or service is selected for migration. This is followed by several of the more interesting examples of hardware/software cooperation in the 432. A comparison of cooperation in the 432 with several contemporary machines and discussions of development issues, past and future, complete the paper.

The dynamic storage management for increasing a programming language power

The runtime storage management system used by typical SIMULA implementations is outlined. The consequences of its global approach, based on the exclusively dynamic nature of the execution data, are assessed.