The Memory Fragmentation Problem Solved Mark S Johnstone

The Memory Fragmentation Problem: Solved? Mark S. Johnstone Paul R. Wilson Presented by David Oren (doren@math. tau. ac. il)

Dynamic Memory Allocation z. Memory is y. Allocated by the running process y. Freed when no longer needed z. The allocator handles those requests, and keeps track of used and unused memory z. No garbage collection, no compaction

What Is Fragmentation? z. Inefficient use of memory, or… z. The inability to use free memory z. There are two types of fragmentation: y. External fragmentation y. Internal fragmentation

External Fragmentation z. Arises when free blocks are available, but cannot be used to hold objects of the sizes requested z. This can have several reasons: y. The free blocks are too small y. The allocator is unable to split larger blocks

Internal Fragmentation z. Arises when a block is allocated, but it is larger than needed: the rest is wasted z. This can have several reasons: y. Architecture constraints y. Allocator policy

Allocator policies z. Policies fall into three basic categories: y. Sequential fits y. Segregated free lists y. Buddy systems

Sequential fit z. Classic implementations: y. Doubly linked linear or circular list y. FIFO, LIFO or address order y. First, next of best fit z. Instances of policies z. There are more efficient implementations

First fit z. Search the list of free blocks from the beginning z. Use first large enough block, split if needed 4 Easy to implement 7 Lots of small blocks at the beginning

Next fit z. A common optimization on first fit z. Each search begins where the previous one ended 4 No accumulation of small blocks 8 Generally increases fragmentation

Best fit z. Use the smallest block large enough 4 Minimize the amount of wasted space 8 Sequential best-fit is inefficient

Segregated free lists z. Use a set of lists of free blocks z. Each list hold blocks of a given size y. A freed block is pushed onto the relevant list y. When a block is needed, the relevant list is used

Simple segregated storage z. All blocks in the list are of the same size z. Large free blocks are not split z. Smaller blocks are not coalesced 4 Efficient implementation 8 Internal fragmentation

Segregated fit algorithms z. Free list contain several sizes z. When memory is requested y. The relevant list is (sequentially) searched y. If no block is found, the other lists are searched, and the block is split z. Freed blocks are coalesced 4 Approximates best-fit

Buddy systems z. Memory is conceptually split into “buddies” z. Only “buddies” may be coalesced 4 Very easy coalescing 8 Internal fragmentation (but may use several buddy-systems to reduce it)

Test Method z. Allocators were traditionally tested with synthetically generated allocations z. However, we cannot be certain that they resemble real programs z. Therefore, the test was conducted using real programs

Test Program Criterions z. Allocation intensive programs z. Programs with large amount of live data z. A wide variety of program types z. Avoiding over-representation of one type z. Non-leaking programs

Test Programs z. In the end, eight programs were chosen z. They present a variety of different memory usage requirements z. It can still be argued whether they are representative of real-life problems

Test Programs z Espresso z gcc (2. 5. 1) z Ghostscript z Grobner z Hyper z LRUsim z P 2 C z Perl

Program Statistics

Testing Methods z. The goal is to test policy, not implementation z. The allocators were tested offline, not incorporated into running programs z. Runtime was not tested

Testing Methods (Cont. ) z. Testing was done in three steps: y. Replacing memory allocation functions with new ones, which create a trace of calls y. Reading the trace, and extracting statistics about the program y. Reading the trace, and calling the allocation functions of the policy being tested (keeping track of allocation from the OS)

Removing Overhead z. Header and footer overhead y. Less memory was allocated in the simulation than the program requested z. Alignment overhead y. The amount of allocated memory was multiplied by 16 y. The amount requested from the OS was divided by 16

Defining Fragmentation z. There are different definitions of fragmentation z. We define it as percentages over and above the amount of live data z. Fragmentation can be measured in several ways

Measuring Fragmentation z. We have chosen two methods: y. Maximum amount of memory used by the allocator, relative to the amount requested by the program, at the point of maximum memory usage y. Maximum amount of memory used by the allocator, relative to the maximum amount of live memory

Other Measures z. Other measures are also interesting z. There is no “right” way to measure fragmentation z. Fragmentation should be measured for those conditions under which it is a problem

Experimental Error z. Generally, memory was requested from the OS in blocks of 4 kb z. The measurement of the heap size can be an over-estimate by no more than 4 kb z. This amount should be divided by 16, yielding 256 bytes

Results

Strategy z. There is a relation between the successful policies y. They all immediately coalesce memory y. They reallocate objects that have died recently z. This can be called a good strategy

Best fit z. Tries to use small free blocks z. This gives neighbors of large blocks time to die z. They are merged into yet larger blocks z. When a large block is split, it is likely to be used again

AO first-fit z. Allocate blocks from one end of the heap z. Blocks at the other end have more time to die and merge into larger blocks z. This is obviously not true for next-fit policies

Lifetime z. Objects allocated at the same time tend to die at the same time z. On average, after 2. 5 Kb of allocation, 90% of all objects have both neighbors free z. It pays to wait a short time after an object is freed

Object size z. On average 90% of allocated objects have 6 sizes z. Many memory requests are for objects of the same size as freed ones z. Good allocators should use this fact z. There is no reason to increase internal fragmentation

Conclusions z…“we arrive at the conclusion that the fragmentation problem is a problem of recognizing that good allocation policies already exist, and have inexpensive implementations. ”