Browse Prior Art Database

Memory Manager for Application Programs in OS/2

IP.com Disclosure Number: IPCOM000108211D
Original Publication Date: 1992-May-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 2 page(s) / 80K

Publishing Venue

IBM

Related People

Cox, DR: AUTHOR [+3]

Abstract

This article describes a method to easily manage memory obtained from OS/2* without each application writing extensive application code to keep track of that memory. The OS/2 APIs used to obtain and free memory management provide no mechanism to keep track of the segments allocated by an application program. Nor do other memory management implementations, such as the 'C' language runtime implementation, provide this tracking. Each application must keep track of the segments which have been allocated, and the subsets within those segments, so that the memory can be freed when it is no longer needed.

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

Memory Manager for Application Programs in OS/2

       This article describes a method to easily manage memory
obtained from OS/2* without each application writing extensive
application code to keep track of that memory. The OS/2 APIs used to
obtain and free memory management provide no mechanism to keep track
of the segments allocated by an application program.  Nor do other
memory management implementations, such as the 'C' language runtime
implementation, provide this tracking.  Each application must keep
track of the segments which have been allocated, and the subsets
within those segments, so that the memory can be freed when it is no
longer needed.

      Due to the level of application code which would be required to
maintain proper memory management within an application, many
application programs simply allow the system to free associated
memory when a program is terminated.  This, however, causes unneeded
memory to remain in storage, and can cause the OS/2 system to swap.
Additionally, segments which are shared reside in the LDT for each
process in the system, causing additional performance overhead in
OS/2 if they are not removed when they are no longer needed.

      In order to overcome these problems in our application systems,
OfficeVision*/2 (OV/2) Office built a Memory Management subsystem,
providing a layer of independence between application programs and
the OS/2 operating system. This thin layer of code is responsible for
keeping track of memory requested by a calling application.  The
Memory Management subsystem tracks each segment allocated by a
calling application in a memory pool.  This memory pool is identified
by a handle, which the calling application p...