You are currently on IBM Systems Media’s archival website. Click here to view our new website.

AIX > Tips & Techniques > Application Development

A Framework for the User-Defined Malloc Replacement Feature

Note: This article originally appeared on IBM's eServer Developer Domain Web site.

A common issue when porting or developing applications on AIX* is that of customized memory allocation tools. Developers often wish to use an implementation of the malloc() and friends system library routines that allows detailed debugging, monitoring and analysis of an application's dynamic memory utilization. In case of cross-platform development, an organization may have a single implementation of these common memory management functions that run on all of the systems.

Since the release of AIX 4.3.3, a feature has been available that allows the use of a user-supplied memory allocation subsystem. This feature, known as the User Defined Malloc Replacement Facility, allows the dynamic loading of a plug-in that supplies a well-defined set of symbol definitions that will be invoked by all components of the running application.

This article explores the details of creating a malloc replacement mechanism. Included are an explanation of the code necessary for taking advantage of this feature and strategies to incorporate support for threaded processes.

The Basics
Visit IBM's AIX Web site and
search a current version of the AIX documentation for the phrase, "User Defined Malloc Replacement." This document defines the basic requirements for a plug-in, including the complete set of function declarations that the plug-in must define, the method for indicating that an application should use the plug-in and a number of restrictions on plug-in naming and location. This article assumes that readers have read the documentation and are aware of its contents.

Let's start by reviewing the set of required functions. This set can be broken into three groups as shown in Table 1. The first group is the basic programming interface for the memory allocation subsystem. The second group contains an initialization function, called only once during program execution, an optimization function for controlling the behavior of the subsystem and an information function that can be used to return data about the behavior and performance of the subsystem to the application. The functions in the final group are used to serialize access to the subsystem across the fork() system call. (Note: More information about threaded applications and the fork() system call can be found in the AIX documentation link mentioned previously. Refer to the information on fork() and pthread_atfork() in the "Base Operating System Technical Reference," as well as the "Threads Programming Guidelines" chapter in the "General Programming Concepts" manual.) These functions are referenced throughout the remainder of this article without the leading or trailing underscores for the sake of visual clarity. The first step in creating a plug-in is to implement the primary API as listed in Table 1.

Figure 1 shows our version of malloc(). Each allocated block starts with a header containing a size field, plus padding to ensure alignment requirements are met. Every request size is rounded up to the next multiple of 8 bytes; the original size of the request is stored in the header, and the sbrk() system call is used to acquire the memory. Because the padding has no other purpose at this time, a signature will be written to it. This may be useful if we add debugging code later on. A pointer to the actual buffer is returned to the caller. Finally, two static variables are used to collect simple statistics.

The free() function (Figure 2) essentially does nothing other than incrementing a counter. The realloc() function allocates a buffer and moves the memory contents to the new location; calloc() is built on top of malloc() with the added function of initializing the memory block with null bytes.



Creating a plug-in becomes a matter of incorporating your memory allocation sub-system code with this framework.

Gary Hook is a senior technical consultant with IBM PartnerWorld for Developers, System p. He can be reached at



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters