Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transparent Pooling in User Controlled Heaps

IP.com Disclosure Number: IPCOM000118050D
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 116K

Publishing Venue

IBM

Related People

Benayon, JW: AUTHOR

Abstract

Most memory management algorithms treat all sizes equally with respect to allocation policies. In practice, applications tend to allocate objects of many sizes, yet few sizes will dominate all the allocations required for the program. Therefore, if the user can indicate the range of preferred sizes to the memory allocator for pooling, performance can be greatly improved during allocation and deallocation of objects, thus resulting in faster execution and reduced page swapping.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Transparent Pooling in User Controlled Heaps

      Most memory management algorithms treat all sizes equally with
respect to allocation policies.  In practice, applications tend to
allocate objects of many sizes, yet few sizes will dominate all the
allocations required for the program.  Therefore, if the user can
indicate the range of preferred sizes to the memory allocator for
pooling, performance can be greatly improved during allocation and
deallocation of objects, thus resulting in faster execution and
reduced page swapping.

      In most deallocation algorithms, an attempt is made to coalesce
a freed object with other objects in the free heap, resulting in an
expensive operation with respect to processing and page swapping.
The advantage of this coalescing is that the heap will always reuse
the freed  object to satisfy future smaller and same size requests,
thus minimizing  the working set size.  The disadvantage is clearly
seen when an application repetitively allocates and deallocates a
common size such that the coalescing is immediately split in a
subsequent heap operation.  It is for this type of application that a
substantial improvement in speed is gained with transparent pooling
in multiple heaps.

      In the IBM* VisualAge* C++ product for OS/2* and Windows** NT
platforms, support for user controlled multiple heaps is provided.
This allows the user to provide a call-back interface when
expanding/shrinking the heap and direct the base malloc routines to
allocate from this private heap.  Through the usage of the callback
routines, the user is  able to provide any type of memory such as
tiled, shared, non-shared, stack, static, etc. to the allocator for
future heap operations.  The allocator is not aware of the
accessibility to the storage by other processes, thus it is unable to
allocate memory from the system directly  for internal structures and
must rely on the callbacks routines to acquire memory.

      The solution to the above performance problem is for the user
to supply a range of object sizes that an allocator should provide
optimal performance with respect to speed and page swapping.  This is
accomplished via a function interface that accepts a heap handle to a
user defined heap, minimum size, maximum size, growth size, and flags
as follows:
  int _upool(Heap_t uh, size_t min_sz, size_t max_sz,
              size_t incr_qty, size_t flags)

      The memory allocator will utilize the range of sizes during an
allocation to acquire storage from a faster data structure than that
used for other sizes.  Similarly.  a deallocation will place the
object in this new structure for future allocations thus preventing
an unnecessary coalesce.  The incr_qty parameter is required so the
pool will create 'incr_qty' items of a particular size when the pool
is empty and needs to be expanded.  The flags parameter allows the
user to provide further options to the allocator for performance...