vxworks memory allocation wp - Semantic Scholarimplementation. For more details about the API provided by these libraries, see the VxWorks API Reference Guide. The best-ﬁ t implementation

Copyright © 2005 Wind River Systems, Inc

Memory Allocation in VxWorks 6.0White Paper

Zoltan LaszloWind River Systems, Inc.

1 MEMORY ALLOCATION IN VXWORKS 6.0 Copyright © 2005 Wind River Systems, Inc. 1 MEMORY ALLOCATION IN VXWORKS 6.0

1 IntroductionMemory allocation is a typical software engineering problem for which there are numerous solutions, but each requires compromises. The evaluation criteria of a memory allocator usually include execution speed, memory overhead, and vulnerability to internal and external fragmentation [Ran69, WJN95]. What makes evaluation diffi cult is that allocation patterns differ signifi cantly from application to application, system to system. A given allocator could perform well under certain allocation pattern, but perform poorly under a different pattern. For this reason, it is diffi cult to implement a one-size-fi ts-all, general purpose memory allocator.

In this paper, two different implementations of the memory allocation library of VxWorks are evaluated and compared. In earlier version of VxWorks, a simple memory allocation library was used. The implementation was based on the fi rst fi t allocation policy, with free memory blocks stored in a linked list. At the time, this library was satisfactory due to the hard real-time nature of the typical applications run on VxWorks. The expectation was that resources are created and allocated mostly during system initialization, and rarely freed or destroyed. Over time, as the complexity of the applications grew, and standards such as C++, Java, and POSIX became more widely used in device software development, the performance of dynamic memory management became more important. In VxWorks 6.0, a new implementation of the memory allocation library was introduced. This new implementation is based on the best-fi t allocation policy, resulting in less susceptibility to fragmentation and more deterministic execution time.

2 First-fi t allocationWith fi rst-fi t allocation policy, there is no attempt made to order the free blocks in any way. Free blocks can be stored in a simple linked list, and the search algorithm is simply to walk the list until a free memory block large enough to satisfy the request is found. When freeing memory, unless the block can be coalesced to one of the adjacent blocks, the block being freed is inserted at the head of the linked list. Figure 1 shows the linear memory representation of the free blocks linked in a simple list.

The fi rst-fi t allocation policy results in relatively small memory overhead and simple block search algorithm. In the best-case scenario, the fi rst block on the free list can satisfy the request; this results in very fast allocation. However, if dynamic allocation and freeing are performed, the memory managed inevitably becomes fragmented over time. With fi rst-fi t policy, larger blocks are more likely to be split in two, with the remainder of the block becoming a smaller free block on the list. To make things worse, the small fragments created after splitting larger blocks are less likely to get used up, because they are too small for the new blocks being allocated; therefore, they will end up queued in the front of the list. Searching for larger blocks requires walking over these small blocks, resulting in signifi cantly reduced worst-case and average allocation performance.

Root Free FreeAlloc Alloc Alloc Alloc Alloc AllocFree Free

Figure 1. Linked list of free blocks


3 Best-fi t allocationWith best-fi t allocation policy, the set of free blocks has to be searched for the smallest-sized block that is big enough to satisfy the request. In order to make such search acceptable, a more complex data structure to store the free blocks has to be used (e.g., binary tree). Maintaining this data requires increased overhead and more complex algorithms, compared to the fi rst-fi t policy. Figure 2 shows the linear memory and logical representation of a heap with fi ve free blocks of sizes 200, 2x100, and 2x300 bytes.

Whenever a new size is created, a new node is inserted in the tree. When blocks of a certain size are all used up, the corresponding node is removed from the tree. After such changes, the tree is rebalanced in order to maintain ideal search time.

The advantage of the best-fi t allocation policy is that the probability of a larger block having to be split is smaller. Second, free blocks of the same size can be grouped together; this reduces the number of nodes that need to be searched. Finally, with the ordered data structures, a signifi cantly more effi cient searching algorithm can be used. For a balanced binary tree, for example, the search has O(log(n)) complexity, compared with the linear search¾with O(n) complexity¾used in the fi rst-fi t implementation. All these result in signifi cantly better worst-case performance. In other words, the result is a more deterministic allocation time.

Root

Root

200 F1

F1200

F2100Alloc Alloc Alloc Alloc F4

100 AllocF3300

F5300

300 F5 F3100 F2 F4

Figure 2. Tree of lists structure of free blocks


4 Performance evaluationIn this section, the two implementations are compared based on allocation time, fragmentation, and code size. Note that these benchmark results should be considered without a time unit in mind. The goal is only to provide a qualitative comparison of two algorithms under similar conditions (i.e., identical target platform and identical confi guration), and not a quantitative benchmark result. Therefore, the time units are omitted from the graphs.

In these benchmarks, each allocation is for a weighted random number of bytes, with smaller blocks (tens of bytes) being allocated with higher probability than larger blocks (hundreds of bytes). Such an allocation pattern has been shown to be closer to real-world allocation patterns of various applications [WJN95]. Figure 3 shows the distribution of the number of allocated blocks as a function of block size.

4.1 Allocation time and fragmentation with identical allocation pattern

This section presents benchmark results for the best-fi t and fi rst-fi t memory allocators running an identical memory allocation pattern, as explained above. Figure 4 shows the number of free blocks and the average allocation time as a function of the number of elapsed cycles. Each cycle represents a fi xed number of allocation and free operations.

The graphs show near constant allocation time and a very small number of free blocks for the best-fi t algorithm. Under the same conditions, the fi rst-fi t algorithm incurs signifi cant fragmentation (a large number of free blocks) and increasing average allocation time. However, early on, while fragmentation is still low, the fi rst-fi t algorithm results in better allocation time. This difference results from the cost of maintaining the balanced tree that stores the free blocks.

Figure 3. Distribution of block sizes


Figure 4. Allocation time and fragmentation

4.2 Allocation time as a function of fragmentation level

This section shows benchmark results for allocation and free operations under similar fragmentation levels (a higher number of free blocks means increased fragmentation). Each measurement in Figure 5 represents an average of 100 allocations of different sizes. The size distribution of the allocations is similar to the one shown in Figure 3.


Figure 5. Allocation time As the results show, the best-fi t algorithm performs more deterministically, with near constant allocation and free time under the measured range (in reality, the result is logarithmic, but the increase in time is becoming more signifi cant under much higher fragmentation levels only). At the same time, the allocation time for the fi rst-fi t algorithm increases linearly with the fragmentation. Freeing is near constant for the fi rst-fi t allocator as well. The slightly faster freeing time of the fi rst-fi t algorithm results from its simple method of inserting free blocks at the head of the free list.

4.3 Library size

In this section, the size of the allocator libraries, memPartLib and memLib, are compared. The two libraries together implement the full set of memory partition and heap management routines. Table 1 shows library sizes (in bytes) for the best-fi t and fi rst-fi t implementations. However, note that the increase for best-fi t implementation is not entirely due to the new allocation policy; it also provides additional reliability and error detection enhancements not available in the fi rst-fi t implementation. For more details about the API provided by these libraries, see the VxWorks API Reference Guide. The best-fi t implementation also uses a shared utility for managing binary trees. Since this utility is also used by other VxWorks kernel libraries, its size is not counted here.


First-Fit Best-Fit

text data bss text data bss

memPartLib 4012 44 188 5858 56 356

memLib 2752 12 4 3896 12 0

TOTAL 7012 10178

5 SummaryDynamic memory allocation is becoming an increasingly important performance criterion in device software development. Increased reliance on allocations means memory is more likely to become fragmented over time, reducing the ability of systems to function reliably over extended period of time. The best-fi t allocation policy employed in VxWorks 6.0’s memory partition library provides reduced vulnerability to fragmentation and has a more deterministic allocation time. Improved overall performance, however, comes at the cost of increased complexity and code size, due to the more complicated method of storing the free block information. Also, allocation time at very low fragmentation levels with the best-fi t algorithm can be slower compared to the fi rst-fi t algorithm.

6 References[WJN95] Paul R. Wilson, Mark S. Johnstone, Michael Neely, and David Boles. “Dynamic

Storage Allocation: A Survey and Critical Review” in International Workshop on Memory Management. Kinross: Scotland, UK. September 1995.

[Ran69] Brian Randell. “A note on storage fragmentation and program segmentation.” Communications of the ACM, 12(7):365-372. July 1969.

Table 1. Code size of fi rst-fi t and best-fi t allocators

Documents

vxworks memory allocation wp - Semantic Scholarimplementation. For more details about the API provided by these libraries, see the VxWorks API Reference Guide. The best-ﬁ t implementation