Hummingbird Measurements

Table 3 shows the final heap size and the heap fragmentation at the end of the Hummingbird trace. It also shows the CPU consumption for running the malloc on the full trace. The execution time column in Table 3 indicates that increased CPU consumption does not correspond to reduction in fragmentation. The best malloc is not the slowest, and the fastest malloc does not cause most fragmentation.

Figure 7 shows the heap size of the same mallocs as a function of the time. The rightmost point in all graphs in Figure 7 is the final heap size shown in Table 3. Note that the fragmentation described in Table 3 is independent of the operating system we used. Executing the same malloc code on a different operating system will cause similar fragmentation.

Table 3 shows that the heap fragmentation ranges from 30.5% to infinity (heap overflow). Moreover, most mallocs do not reuse memory properly, which is indicated by continuously increasing heap size in Figure 7.

PhK/BSD performed best among all the studied mallocs for the Hummingbird trace. Not only it had the smallest heap fragmentation, it also did a better job at reclaiming freed areas. Figure 8 compares the heap size of the four best mallocs: PhK/BSD, Solaris default, GNU and modified bin buddy with the live memory. Figure 8 has the same time scale as Figure 7.

Figure 8 indicates that the Solaris default, GNU and modified bin buddy mallocs allocated some area on the heap, and they were not able (or not designed to) reduce the heap size if there was an opportunity to do so. Such an opportunity arises when the last memory area in the heap is freed. Only PhK/BSD was able to reduce the heap size on these occasions, which may explain its overall better operation.