Dynamic memory allocation has been a fundamental part of most computer systems since roughly 1960, and memory allocation is widely considered to be either a solved problem or an insoluble one. In this survey, we describe a variety of memory allocator designs and point out issues relevant to their design and evaluation. We then chronologically survey most of the literature on allocators between 1961 and 1995. (Scores of papers are discussed, in varying detail, and over 150 references are given.) We argue that allocator designs have been unduly restricted by an emphasis on mechanism, rather than policy, while the latter is more important; higher-level strategic issues are still more important, but have not been given much attention. Most theoretical analyses and empirical allocator evaluations to date have relied on very strong assumptions of randomness and independence, but real program behavior exhibits important regularities that must be exploited if allocators are to perform well in practice.

Introduction Dynamic memory allocation is an integral part of programming. Programs in C and C++ (via constructors and destructors) routinely allocate memory using the familiar ANSI-C standard interface malloc established around 1979 by Doug McIlroy. Malloc manipulates heap memory using the functions malloc(s) to allocate a block of size s, free(b) to free a previously allocated block b, and realloc(b,s) to resize a block b to size s. No optimal solution to dynamic memory allocation exists [1, 2, 3] so, over the years, many malloc implementations were proposed with different tradeoffs in time and space efficiency. A study by David Korn and Phong Vo in 1985 presented and compared 11 malloc versions. Only a few of these survived the test of time. The first widely used malloc was written by McIlroy and became part of many Bell Labs Research and System V versions of the UNIX system. This malloc is based on a first-fit strategy and can be significantly slow in large memories. C. King

Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer (TLB) to map a large physical memory region into a virtual address space. This dramatically increases TLB coverage, reduces TLB misses, and promises performance improvements for many applications. However, supporting superpages poses several challenges to the operating system, in terms of superpage allocation and promotion tradeoffs, fragmentation control, etc. We analyze these issues, and propose the design of an effective superpage management system. We implement it in FreeBSD on the Alpha CPU, and evaluate it on real workloads and benchmarks. We obtain substantial performance benefits, often exceeding 30%; these benefits are sustained even under stressful workload scenarios. 1

We describe an algorithm that efficiently implements the first-fit strategy for dynamic storage allocation. The algorithm imposes a storage overhead of only one word per allocated block (plus a few percent of the total space used for dynamic storage), and the time required to allocate or free a block is O(log W), where W is the maximum number of words allocated dynamically. The algorithm is faster than many commonly used algorithms, especially when many small blocks are allocated, and has good worst-case behavior. It is relatively easy to implement and could be used internally by an operating system or to provide run-time support for high-level languages such as Pascal and Ada. A Pascal implementation is given in the Appendix.

resource functions Discipline Methods Resource definition Algorithms Resource acquisition Management styles Event handling Special modes Figure 1: The discipline and method architecture Figure 1 summarizes the discipline and method library architecture. Four main interface constructs are used to manage resources: ffl Handle: A handle holds resources and states that need to be maintained across operations. ffl Operations: Library operations create/delete handles and access handle resources. ffl Discipline: A discipline type publically and uniformly defines certain resource requirements. ffl Methods: Methods encapsulate different operational or performance characteristics. The top two parts of Figure 1 constitute the familiar handle and operations architecture of many traditional libraries such as the ANSI-C Stdio library [1] and the STL template libraries. [4] This architecture is simple and easy for both library writers and application developers to learn and use. Howeve...

Over the past few years, my colleagues and I have written and distributed a number of general purpose libraries covering a wide range of computing areas such as I/O, memory allocation, container data types, and sorting. Published studies showed that these libraries are more general, flexible and efficient than comparable packages as application construction tools. Our libraries are based on an architecture in which two main interfaces are made explicit: disciplines to define resource requirements, and methods to define resource management. This paper discusses the discipline and method library architecture and a resource-oriented analysis approach for analyzing and designing libraries based on this architecture. 1 Introduction Building software libraries is a good way to capture domain knowledge in reusable code. The popularization of languages such as C and C++ and operating systems such as UNIX and WINDOWS has brought about a plethora of libraries covering a wide range of functions ...

this paper is to present the details of our new allocator, it is important to demonstrate that the allocator can work in conjunction with (at least) a simple collector without compromising the worst-case behaviour. We therefore present in this section a garbage collector that is both scalable and non-disruptive (though it does not collect cycles).