Browse Prior Art Database

Dynamic Extension Modules in a Custom Memory Allocator

IP.com Disclosure Number: IPCOM000230086D
Publication Date: 2013-Aug-18
Document File: 3 page(s) / 25K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to dynamically install and remove memory allocator extensions without interrupting the running program and to automatically trigger installing or removing an extension based on resource utilization or the occurrence of arbitrary events. The disclosed method correctly handles object deletion when that object is created with a different extension installed or a different instance of the same extension.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 3

Dynamic Extension Modules in a Custom Memory Allocator

Specialized computer systems (i.e., appliances) frequently need to run a relatively small subset of programs for a long time. Since the nature of these programs is known in advance, such programs can benefit from custom memory allocators better suited to the associated workload characteristics than general memory allocators. A custom

memory allocator may include various extensions to facilitate problem discovery, such as memory leaks or use-after-free. Since an appliance should be rebooted as little as possible, a custom memory allocator that is capable of dynamically installing or removing a given extension "on-the-fly" without interrupting the running program is

desirable.

Proper handling of dynamic memory allocator extensions poses significant challenges. For example, an object can be allocated when one extension is installed and then freed after that extension has been removed. Another challenge is with extensions that keep

track of allocated objects; even if the extension at allocate time and free time is the same one, the allocator still needs to handle the case if that extension was removed between two events, thus making tracking data invalid. A further issue is handling

serialization between heavy allocation traffic and extension install/remove.

The solution is a method to dynamically install and remove memory allocator extensions without interrupting the running program. In addition, the method correctly handles an object deletion when that object is created with a different extension installed or a different instance of the same extension.

When no extensions are installed, the custom memory allocator is said to be the Base allocator. During normal system operation, the Base allocator runs, providing the best possible performance. Allocator extensions logically run on top of the Base allocator,

keeping track of additional data such as a callstack of the thread making an allocation request, to track sources of memory leaks.

Every allocated object has a fixed-size header and an extension-dependent suffix. A

typical object memory space managed by the base allocator is shown below.

Figure: Typical object memory space managed by the Base allocator

The object header is used by the Base allocator to track memory allocations, the memory object is the memory requested by the caller, and the object suffix is used by the extension to store additional data. When an extension registers with the Base allocator, it declares how large a suffix it needs and provides a unique identification value. The Base allocator has an object suffix size of zero.

At object allocation time, the Base memory allocator determines whether an extension is active, provides enough memory for header + object + suffix, sets the extension field

1


Page 02 of 3

in the header, and passes the object to the extension.

The extension uses the suffix fields as it sees fit, completely transparent to the Base allocat...