Programmers hoping to achieve performance improvements often use custom memory allocators. This in-depth study examines eight applications that use custom allocators. Surprisingly, for six of these applications, a state-of-the-art general-purpose allocator (the Lea allocator) performs as well as or better than the custom allocators. The two exceptions use regions, which deliver higher performance (improvements of up to 44%). Regions also reduce programmer burden and eliminate a source of memory leaks. However, we show that the inability of programmers to free individual objects within regions can lead to a substantial increase in memory consumption. Worse, this limitation precludes the use of regions for common programming idioms, reducing their usefulness. We present a generalization of general-purpose and region-based allocators that we call reaps. Reaps are a combination of regions and heaps, providing a full range of region semantics with the addition of individual object deletion. We show that our implementation of reaps provides high performance, outperforming other allocators with region-like semantics. We then use a case study to demonstrate the space advantages and software engineering benefits of reaps in practice. Our results indicate that programmers needing fast regions should use reaps, and that most programmers considering custom allocators should instead use the Lea allocator.

Memory management is a critical issue for many large object-oriented applications, but in C++ only explicit memory reclamation through the delete operator is generally available. We analyse different possibilities for memory management in C++ and present a dynamic memory management framework which can be customised to the need of specific applications. The framework allows full integration and coexistence of different memory management techniques. The Customisable Memory Management (CMM) is based on a primary collector which exploits an evolution of Bartlett's mostly copying garbage collector. Specialised collectors can be built for separate memory heaps. A Heap class encapsulates the allocation strategy for each heap. We show how to emulate different garbage collection styles or user-specific memory management techniques. The CMM is implemented in C++ without any special support in the language or the compiler. The techniques used in the CMM are general enough to be applicable also to...

Large-scale database, data mining, and multimedia applications require large, sequential transfers and have bandwidth as a key requirement. This paper investigates the performance of reading and writing large sequential files using the Windows NT ™ 4.0 File System. The study explores the performance of Intel Pentium Pro ™ based memory and IO subsystems, including the processor bus, the PCI bus, the SCSI bus, the disk controllers, and the disk media in a typical server or high-end desktop system. We provide details of the overhead costs at each level of the system and examine a variety of the available tuning knobs. We show that NTFS out-of-the-box performance is quite good, but overheads for small requests can be quite high. The best performance is achieved by using large requests, bypassing the file system cache, spreading the data across many disks and controllers, and using deep-asynchronous requests. This combination allows us to reach or exceed the half-power point of all the individual hardware components. 1

Modern software systems are often built from existing library components. A common problem is how to fix bugs when source code is not available. Xept is an instrumentation language and tool that can be used to add to object code the ability to detect, mask, recover and propagate exceptions from library functions. This helps to alleviate or avoid a large class of errors resulting from function misuses. Examples will be given to show applications of Xept in actual software systems. 1. Introduction Modern software systems are often built out of reusable components from diverse sources, including freeware or software vendors. For various reasons, including proprietary concerns, source code for such components is often not available. Thus, unless the original developers are still around and willing to help, bugs in such components are often left unfixed. This points out a need for tools and approaches to handle bugs in object code. This is not a generally solvable problem because bugs can a...

The Software Engineering Research department at Murray Hill writes and distributes several widely used development tools and reusable libraries that are portable across virtually all UNIX platforms. [1] To enhance reuse of these tools and libraries, we want to make them available on systems running Windows NT [2] and/or Windows 95 [3] . We did not want to support multiple versions of these libraries, and we wanted to minimize the amount of conditionally compiled code. This paper describes an effort of trying to build a UNIX interface layer on top of the Windows NT and Windows 95 operating system. The goal was to build an open environment rich enough to be both a good development environment and a suitable execution environment. This meant that the overhead needed to be small enough so that there was no incentive to program to the native operating system directly. The openness meant that the complete facilities of the native operating system were accessible through this environmen...

On the vast majority of today’s computers, the dominant form of computation is GUI-based user interaction. In such an environment, the user’s perception is the final arbiter of performance. Human-factors research shows that a user’s perception of performance is affected by unexpectedly long delays. However, most performance-tuning techniques currently rely on throughput-sensitive benchmarks. While these techniques improve the average performance of the system, they do little to detect or eliminate response-time variabilities—in particular, unexpectedly long delays. We introduce a measurement infrastructure that allows us to improve user-perceived performance by helping us to identify and eliminate the causes of the unexpected long response times that users find unacceptable. We describe TIPME (The Interactive Performance Monitoring Environment), a collection of measurement tools that allowed us to quickly and easily diagnose interactive performance “bugs” in a mature operating system. We present two case studies that demonstrate the effectiveness of our measurement infrastructure. Each of the performance problems we identify drastically affects variability in response time in a mature system, demonstrating that current tuning techniques do not address this class of performance problems.

To my wife and family.

Workstation-based parallel processing is an area that is still dominated by Unix-based systems. We have been building new methods for shared-memory parallel processing systems on top of Windows NT based networks of machines. As of present we have been involved in four related systems, called Calypso NT, Chime, Malaxis and MILAN. All of these are middleware, that is they are system level libraries and utility programs that allow programmers to utilize a network efficiently for high volume computations. Calypso was first built on Unix [BDK95], and then ported to Windows NT. Chime and Malaxis are NT systems and MILAN is still under the design phase. This paper describes the systems, the techniques used to implement them on Windows NT and the roadblocks from a Unix programmer's point of view. 1. Introduction This paper describes the experience of porting to and programming with Windows NT (from a Unix programmer 's perspective) while implementing four related parallel processing projec...

Parallel Programming Systems based on the Distributed Shared Memory technique has been promoted as easy to program, natural and equivalent to multiprocessor systems. However, most programmers find this is not the case. The shared memory in DSM systems do not have the same access and sharing semantics as shared memory in real multiprocessor systems (shared memory multiprocessors). We present a scheme, which has been implemented as a part of the Chime Parallel Processing system, that provides, true shared-memory multiprocessor semantics in a distributed system. Programs are written as parallel programs with constructs for parallel forloop and parallel compound statement. A runtime system (middleware) provides the above features using a unique multithreaded architecture. In addition to providing the stack sharing support, the runtime system is able to provide nested parallelism, task synchronization, load balancing and fault tolerance. The software is available at http://milan.e...

This paper describes an effort of trying to build a UNIX interface layer on top of the Windows NT [1] and Windows 95 [2] operating system. The goal was to build an open environment rich enough to be both a good development environment and a suitable execution environment. The result of this effort is a set of libraries, headers, and utilities that we collectively refer to as UWIN. UWIN contains nearly all the X/Open Release 4 [3] headers, interfaces, and commands. An earlier paper on porting to Windows NT [4] , describes alternative porting strategies and presents some performance results for UWIN. In this paper we discuss some of the design decisions behind UWIN and some of the results so far as well as some of the remaining challenges. 1. INTRODUCTION The marketplace has dictated the need for software applications to work on a variety of operating system platforms. Yet, maintaining separate source code versions and development environments creates additional expense and requ...