Suballocating Memory

Under OS/2 Version 2.0, the granular unit of memory is the page. This means that the minimum possible memory allocation for a single DosAllocMem() function call is 4KB. For example, if an application requests the allocation of 10 bytes of storage, the operating system will allocate a full 4KB page; the remaining storage in this page will be wasted.

It is therefore recommended that for dynamic allocation of small memory objects for uses such as instance data, each window procedure should use a single DosAllocMem() function call to allocate a storage pool, and subdivide this storage as required using the DosSubAlloc() function, as shown in Figure "Suballocating Memory".

Storage must be suballocated in multiples of 8 bytes. Any requested suballocation which is not a multiple of 8 bytes will have its size rounded up to a multiple of 8 bytes.

Storage to be suballocated must first be allocated using the DosAllocMem() function, and initialized for suballocation using the DosSubSet() function. Note that control information for the suballocation uses 64 bytes of the storage pool; this must be taken into account when determining the size requirements for the pool.

In Figure "Suballocating Memory", the storage in the pool is committed during allocation, since the example assumes that the total storage requirement is known in advance. In situations where the exact size of the storage required is not known, the storage may be allocated but not committed, and the suballocation procedure will then progressively commit storage as required. This is indicated by specifying the DOS_SPARSE_OBJ flag in the DosSubSet() function call.

Memory that has been suballocated using the DosSubAlloc() function may be freed using the DosSubFree() function. The storage is then available for future suballocation. Note, however, that the suballocation procedure does not reorganize suballocated memory objects within a pool. Thus freeing objects within the pool may result in memory fragmentation.

A storage pool initialized for suballocation using the DosSubSet() function should be removed using the DosSubUnset() function before the memory in the pool is freed. This function call releases the operating system resources used by the suballocation procedure.

When using the C Set/2 compiler, the malloc() function may be used to allocate memory. This function has many of the advantages of the DosSubAlloc() function, but avoids the need for the application to explicitly allocate, set and suballocate memory. The malloc() function also provides greater independence for application code from the platform upon which it executes, allowing the application to be more easily migrated to platforms other than OS/2 Version 2.0.

The malloc() function works as follows:

  • The first call to malloc() from a particular application (process) causes malloc() to request a memory object from the operating system. The malloc() service routine adds 16 bytes to the size specified in the function call, and rounds the result upward to the next even power of 2. This amount of memory is then requested from the operating system using a DosAllocMem() call. The operating system will then allocate memory, rounding the service routine's request size upward to the nearest multiple of 4KB. The malloc() function then fulfills the application's request, with some wastage due to the page-granular allocation.

  • For subsequent calls to malloc(), the malloc() service routine first checks whether it has sufficient memory remaining from a previous request; if so, it allocates that memory and returns control to the application. If not, the service routine requests additional memory from the operating system using the DosAllocMem() function.

    Note that the free() function, used to free memory which has been allocated using malloc(), does not return the memory to the operating system; rather, that memory is held by malloc() for future use. In order to return memory to the operating system, the application must issue a heapmin() function call.

    [Back: Dynamically Committing Storage]
    [Next: Exception Handling]