Improving the cache locality of memory allocation

Abstract

The allocation and disposal of memory is a ubiquitous operation in most programs. Rarely do programmers concern themselves with details of memory allocators; most assume that memory allocators provided by the system perform well. This paper presents a performance evaluation of the reference locality of dynamic storage allocation algorithms based on trace-driven simulation of five large allocation-intensive C programs. In this paper, we show how the design of a memory allocator can significantly affect the reference locality for various applications. Our measurements show that poor locality in sequential-fit allocation algorithms reduces program performance, both by increasing paging and cache miss rates. While increased paging can be debilitating on any architecture, cache misses rates are also important for modem computer architectures, We show that algorithms attempting to be space-efficient by coalescing adjacent free objects show poor reference locality, possibly negating the benefits of spaceefficiency, At the other extreme, algorithms can expend considerable effort to increase reference locality yet gain little in total execution performance. Our measurements suggest an allocator design that is both very fast and has good locality of reference,

Symbolic range analysis of pointers

“…Prolangs [Ryder et al, 2001], PtrDist [Zhao et al, 2005] and MallocBench [Grunwald et al, 1993]. As we show in Chapter 4, our analysis is linear on the size of programs.…”

Hoard

“…We use the single-threaded applications from Wilson and Johnstone, and Grunwald and Zorn [12,19]: espresso, an optimizer for programmable logic arrays; Ghostscript, a PostScript interpreter; LRUsim, a locality analyzer, and p2c, a Pascal-to-C translator. We chose these programs because they are allocation-intensive and have single-threaded benchmarks [12,19] Pascal-to-C translator multithreaded benchmarks threadtest each thread repeatedly allocates and then deallocates 100,000/P objects shbench [26] each thread allocates and randomly frees random-sized objects Larson [22] simulates a server: each thread allocates and deallocates objects, and then transfers some objects to other threads to be freed active-false tests active false sharing avoidance passive-false tests passive false sharing avoidance BEMengine [7] object-oriented PDE solver Barnes-Hut [1, 2] n-body particle solver Table 1: Single-and multithreaded benchmarks used in this paper.…”

“…If there is not, Hoard checks the global heap (heap 0) for a superblock. If there is one, Hoard transfers it to heap i, adding the number of bytes in use in the superblock s.u to ui, and the total number of bytes in the superblock S to ai (lines [10][11][12][13][14]. If there are no superblocks in either heap i or heap 0, Hoard allocates a new superblock and inserts it into heap i (line 8).…”

Exterminator

“…We use the latter suite of benchmarks both because they are widely used in memory management studies [3,19,22], and because their high allocation-intensity stresses memory management performance. For all experiments, we fix Exterminator's heap multiplier (value of M) at 2.…”