Memory allocation mechanisms in AIXSkill Level: Intermediate

Uma Chandolu (uchandol@in.ibm.com)Senior Staff Software EngineerIBM

Gargi Srinivas (gargi.srinivas@in.ibm.com)System Software EngineerIBM

21 Sep 2010

Memory management is one of the most important responsibilities of an operatingsystem. It allocates portions of memory to programs at their request and frees it forreuse when no longer needed. This article describes different allocation algorithmswhich are available in AIX® for memory management and their features.

Introduction

An allocation policy refers to the set of data structures and algorithms used torepresent and manage the heap in terms of implementing the memory managementfunctions of allocating, freeing and reallocating memory dynamically.

AIX malloc subsystem supports the following allocation policies:

• Default (Yorktown) allocation policy

• Watson allocation policy

• Malloc 3.1 allocation policy

Overview of default allocation policy

The default allocation policy in AIX is also called Yorktown policy. It maintains the

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 1 of 12

free space in heap as nodes in a Cartesian binary search tree format.

The nodes are arranged left-to-right by address (increasing address to the right) andtop-to-bottom by length (such that no child is larger than its parent).

Figure 1. Cartesian binary search tree for Yorktown policy

When to use Yorktown

• Yorktown is enabled by default on AIX. It is the most widely used andmost stable of all allocation policies, and therefore is suitable for almostall cases.

• Since it is maintained as a tree with varying sized nodes, there are nolimitations on the allocation block sizes.

To enable Yorktown, type the following command:

export MALLOCTYPE=Yorktown

It can be verified for enablement in two ways:

1. Using DBX sub command malloc

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 2 of 12

2. Running command echo $MALLOCTYPE

Yorktown allocation algorithm

Total memory allocated = roundup (n + prefix_size, alignment), where:

• n equals number of bytes requested by the user

• prefix_size equals metadata information

First, the node from the free tree with the lowest address (which is greater than orequal to the requested block size) is removed. If this is larger than what is wanted, itis broken into two pieces. The extra broken block is returned back to the tree and isinserted in the appropriate place in the free tree. The required block size is thenreturned back to the caller.

Yorktown free algorithm

Freeing of memory involves inserting the freed node back to the free tree. Thisfollows the standard root insertion algorithm. Each node in the tree is searched incomparison to the node being freed, and if it adjoins any other node in terms of theaddress, it is joined to that node. This joining of adjacent nodes preventsfragmentation to some extent, because a lot of free nodes, even though they areadjacent with respect to addresses, would be scattered in the tree and will not beavailable for contiguous allocation.

Yorktown reallocation algorithm

If the size of the reallocated block turns out larger than the original block, the originalblock is returned to the free tree so that any possible joining can occur with theadjoining nodes. A new block of the requested size is then allocated. The data ismoved from the original block to the new block, and the new block is returned to thecaller. The old block is freed and is no longer valid. If the size of the reallocatedblock is smaller than the original block, the block is split and the extra block isreturned to the free tree with the required size block being returned to the caller.

Overview of Watson allocation policy

The Watson allocation policy maintains free space in the heap as nodes in twoseparate "red-black trees":

1. Sorted by address

2. Sorted by size

ibm.com/developerWorks developerWorks®

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 3 of 12

Both trees have to be maintained properly for consistency and correctness.

Figure 2. Red-black tree used in Watson allocation policy based on "Sorted byAddress"

Every node in the address tree will have lesser address nodes in its left subtree andhigher address nodes in its right subtree.

Figure 3. Red-black tree used in Watson allocation policy based on "Sorted bySize"

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 4 of 12

Every node in the size tree will have lesser size nodes in its left subtree and greatersize nodes in the right subtree.

When to use Watson

Since Watson maintains its space in a red-black tree, it provides more efficient treeoperations like insertion and searching as compared to other policies.

To enable it, type the following command:

export MALLOCTYPE=Watson

Watson allocation algorithm

Similar to the Yorktown policy, Watson searches the size tree and finds the smallestpossible block suitable for the request. If the block found in the size tree is exactlythe required size, the block is removed from both the size and the address tree andthen returned to the caller.

If a block of sufficient size is not found in the free tree, then the process heap isexpanded using the sbrk() system call, a block of the expanded size is added to thesize and address trees, and allocation continues as before.

Watson free algorithm

ibm.com/developerWorks developerWorks®

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 5 of 12

The node is returned to the address tree first at the root. The tree is traversed tocheck if the node adjoins any other node in the tree with respect to the address. Ifso, the freed node is joined with the node in the tree. Adjoining of nodes in thismanner prevents fragmentation of memory in heap.

Watson reallocation algorithm

If the size of the reallocated block would be larger than the original block, the originalblock is returned to the free tree so that any possible coalescence can occur with theadjoining nodes. A new block of the requested size is then allocated, the data ismoved from the original block to the new block, and the new block is returned to thecaller. If the size of the reallocated block is smaller than the original block, the blockis split and the remainder is returned to the free tree after sending the requiredamount to the caller.

Overview of malloc 3.1 allocation policy

In malloc 3.1, the heap memory is maintained as a hash bucket where each bucketpoints to a linked list having nodes or blocks of only a certain specific size. The sizeof the block is calculated using the following formula (i identifies the bucket number):

size = 2 ^ (i + 4)

Figure 4. Heap memory as a hash bucket in malloc 3.1

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 6 of 12

To enable malloc, use the following command:

export MALLOCTYPE=3.1 for 32 bit programsexport MALLOCTYPE=3.1_64BIT for 64 bit programs

Malloc 3.1 allocation algorithm

A block is allocated from the free pool by first converting the requested bytes to anindex in the bucket array, using the following equation:

needed = requested + 8If needed <= 16,thenbucket = 0If needed >16,thenbucket = (log(needed)/log(2) rounded down to the nearest integer) - 3

ibm.com/developerWorks developerWorks®

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 7 of 12

The size of each block in the linked list pointed by the bucket is block size = 2 ^(bucket + 4). If the list in the bucket is null, memory is allocated using the sbrk()subroutine to add blocks to the list. If the free list is not empty, the block at the headof the list is returned to the caller. The next block on the list then becomes the newhead.

Malloc 3.1 Free algorithm

When a block of memory is returned to the free pool, the bucket index is calculatedjust like it is done with allocation. The block to be freed is then added to the head ofthe free list for that bucket.

Malloc 3.1 reallocation algorithm

During reallocation, the requested size is compared against the existing size of theallocated block. Because of the wide difference among the sizes handled by eachbucket, the new block size can fall into the same bucket as that of the original block.In such cases, the same block is returned. If the needed size happens to be greaterthan the existing block, the block is freed, a new block is allocated from a newbucket, and the data is moved from the old block to the new block.

Malloc 3.1 limitations

The malloc allocation policy is less efficient than the default, and it is notrecommended for use in most cases. This policy rounds off the size of the allocationrequest to the next highest available block. Therefore, we can be allocated morememory than we want.

Sometimes application programs may depend unknowingly on the side effects of themalloc 3.1 allocation policy. For example, let's assume that there is a program whichincorrectly overwrites the number of bytes it has been allocated by malloc. It mayfunction correctly when using the malloc 3.1 policy because, in essence, 3.1 mayhave allocated more memory than it requested. The same program can and shouldfail when it runs with different allocation policy.

However, in some cases, 3.1 may perform better than the other allocation algorithmsby reducing the overhead of data movement during a reallocation, because it havebeen initially allocated more memory than it actually requested.

Additional malloc options

Some additional malloc options are:

• Malloc multiheap

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 8 of 12

• Pool allocation

• Malloc buckets

Malloc multiheap

By default, the malloc subsystem treats the entire process heap as a single entity. Inmultithreaded enviornments multiple threads access the same heap. In this scenariousing a single heap is not very efficient, because when one thread is being servicedand has taken the heap lock, the other threads will have to wait for their turn toaccess the heap. In such cases, this option can be useful.

To enable the multiheap option, use the following:

MALLOCOPTIONS=[multiheap:n] | [considersize]

The options are as described:

• multiheap:nThe maximum number of heaps available to malloc multiheap is 32. Youcan specify "n" number of heaps between 1 to 32 for malloc to use.

• considersizeBy default, malloc multiheap selects the next available heap. If theconsidersize option is specified, malloc multiheap will use a differentalgorithm and select the heap which has enough free space to handle therequest.

Malloc multiheap limitations

• Since a single heap is actually divided into many heaps (up to 32),unnecessary enabling of malloc multiheap can cause severefragmentation. It can also result in a situation where the system will seemto have run out of memory, because the available memory is fragmentedand is not available contiguously.

• Since the considersize option requires some extra processing, using thisoption may slow down the process to some extent.

• Multiheap option is not supported for malloc 3.1 and user definedallocation policies.

Pool allocation

When memory size is less than or equal to 512 bytes, AIX malloc provides a moreefficient frontend to the actual backend functions of malloc. Pool allocation creates

ibm.com/developerWorks developerWorks®

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 9 of 12

for each thread its own malloc pool which avoids lock contention with other threads.At present, the maximum pool size per process for this allocator is limited to 512MB.

To enable pool allocation, use the following:

MALLOCOPTIONS=pool<:max_size>

This basically creates a fixed number of pools with increasing size. There can be128 pools for a 32-bit application and 64 pools for a 64-bit application.

Pool allocation does not work effectively if one thread of the application allocatesmemory and other thread frees the memory.

Malloc buckets

Malloc buckets is an extension to the Yorktown allocation policy. When anapplication requires a large number of small allocation requests, malloc buckets ismore commonly used. It can be used only along with Yorktown malloc policy.

To enable malloc buckets, use the following:

MALLOCOPTIONS=buckets,number_of_buckets:n

Only allocation requests up to 512 bytes can be serviced by the bucket allocator,and any greater requests are automatically forwarded to the Yorktown malloc.

Conclusion

This article covers the essence of the various AIX memory allocation schemes andtheir salient features. Having an overall idea about the various allocation schemescan help you decide on the allocation scheme that best suits your application athand in terms of execution efficiency and performance.

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 10 of 12

Resources

Learn

• The AIX InfoCenter provides more information on system memory allocationusing malloc subsystem, malloc multiheap, and malloc buckets.

• The XML area on developerWorks provides resources you need to advanceyour XML skills, including DTDs, schemas, and XSLT.

• Stay current with developerWorks technical events and webcasts focused on avariety of IBM products and IT industry topics.

• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBMproducts and tools as well as IT industry trends.

• Watch developerWorks on-demand demos ranging from product installation andsetup demos for beginners, to advanced functionality for experienceddevelopers.

Get products and technologies

• Evaluate IBM products in the way that suits you best: Download a product trial,try a product online, use a product in a cloud environment, or spend a few hoursin the SOA Sandbox learning how to implement Service Oriented Architectureefficiently.

Discuss

• Follow developerWorks on Twitter.

• Get involved in the My developerWorks community.

• Participate in the AIX and UNIX® forums:

• AIX Forum

• AIX Forum for developers

• Cluster Systems Management

• Performance Tools Forum

• Virtualization Forum

• More AIX and UNIX Forums

• Get involved in the My developerWorks community. Connect with otherdeveloperWorks users while exploring the developer-driven blogs, forums,groups, and wikis.

ibm.com/developerWorks developerWorks®

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 11 of 12

About the authors

Uma ChandoluUma M. Chandolu works as a Development Support Specialist on AIX.He has five years of extensive hands-on experience in AIXenvironments and demonstrated expertise in AIX system administrationand other subsystems. He has experience interfacing with customersand handling customer-critical situations. He has been recognized asan IBM developerWorks contributing author. He can be contacted atuchandol@in.ibm.com.

Gargi SrinivasGargi Srinivas works as an AIX L3 developer for IBM. She has threeyears of experience on AIX user space components. You can reach herat gargi.srinivas@in.ibm.com

developerWorks® ibm.com/developerWorks

Memory allocation mechanisms in AIX Trademarks© Copyright IBM Corporation 2010 Page 12 of 12