An Experimental Study on Memory Allocators in Multicore and Multithreaded Applications

Monitoring Memory-Related Software Aging: An Exploratory Study

“…This memory usage pattern is not uncommon in many today's applications. Generically, the memory management literature refers to this problem as memory blowup (see [17]). …”

“…However, analyzing carefully the data we note that this trend is not consequence of software aging, but simply the effect of the OS disk cache (so-called buffer-cache). Since the adopted workloads (w1, w2, w3) are disk I/O-intensives, the OS kernel memory management [17] requests unused physical memory to the page-level allocator in order to create additional disk cache objects. This behavior is expected considering that: i) there is free physical memory available in user level, and ii) the disk I/O subsystem is under pressure.…”

“…In general, the predominant size of memory allocations, in average, is less than 64 bytes [17], which is easily obfuscated by the larger variability of many usual background workloads, e.g., in Exp. #2 the average amount of memory leaked is 200 kilobytes within six hours.…”

“…Investigating the mechanics of many memory allocators [17], we learned that memory leaks do not increase the process size immediately to their occurrences. It takes time to be observed from outside of the process heap, since the process size is only increased when a new memory area is requested to the OS in order to extend the saturated heap.…”

“…We observe that the process' RSS increases right after the first section of memory allocations. It occurs because the initial heap, created by the standard memory allocator (i.e., ptmallocv2 [17]), is only 132 kB large, and we requested 1 megabyte of memory. So, new memory areas are added to the process address space making the RSS to increase.…”