Electrical computers and digital processing systems: memory – Storage accessing and control – Memory configuring
Reexamination Certificate
1998-06-02
2004-11-09
Bragdon, Reginald G. (Department: 2188)
Electrical computers and digital processing systems: memory
Storage accessing and control
Memory configuring
C711S171000, C718S107000
Reexamination Certificate
active
06816956
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to improved memory management in a computing environment by permitting the dynamic allocation of multiple memory heaps as required during program execution, and providing the user with direct control over all memory managed or used by each heap.
BACKGROUND OF THE INVENTION
The heap is that area in memory that is generally allocated at the commencement of program execution for dynamically constructing data objects used for executing the application. Traditionally, the heap remains static during program execution, and is destroyed at the completion of the application.
While early programming systems allocated only one heap during program execution, the intermingling of 16-bit and 32-bit code within applications has resulted in more recent operating systems, such as IBM's OS/2™ operating system, providing support for allocating two heaps. Generally, these two heaps are referred to as the regular heap for receiving only 32-bit coded data objects, and tiled heap that is usable either for 16 or 32-bit code.
The so-called regular heap is based on flat or linear pointers (addresses) referenced to a zero-based address. The heap itself, then, can span a very large segment of memory (up to four gigabytes in size) with pointers based on the same flat or zero address base.
Tiled memory, refers to the fact that the pointers are tiled—their base linear addresses are set to be multiples of 64K because of a limitation in 16-bit code precluding the referencing of data objects spanning 64K boundaries.
A further type of heap in recent development is a shared memory heap (whether in regular or tiled format) that would permit data objects to be accessed directly by several applications at once, or by multiple instances of a single application. Clearly, the shared memory concept reduces processing time by avoiding construction of the same data objects in multiple applications and by simplifying the problems of synchronization and coherence where one application modifies the data.
Multiple heaps (that is, even more than two), have been provided in very recent products such as “SmartHeap” of MicroQuill Software Publishing. The value of any double or multiple heap system includes better data locality, the ability to free one heap in a single efficient operation, while retaining data in other heaps, and less contention in multithreaded applications if each thread has its own heap, and this has been accomplished in the prior art through system calls controlled by the runtime library as described below.
As illustrated schematically in
FIG. 1
, an application call to allocate/deallocate additional heap memory (tiled or regular) is issued to the runtime library and is processed by a memory manager located in the library by issuing system calls to the operating system to acquire or release memory for the heap. Under the traditional approach, allocation of additional heap memory is controlled entirely by the runtime library, not by the user.
In “A List Box Replacement”—Benge, mark A. and Smith, Matt, OS/2 Developer, January/February 1994, pages 66 to 70, a modification of the traditional memory management system is described that is claimed to permit the user somewhat more flexibility in allocating memory from different heaps and to guarantee minimal memory configurations when required by the user. A new HeapAlloc call initiates the heap by requesting a block of memory using a DosAllocMem system call. The address returned by DosAllocMem is the starting chunk of memory for the heap and is invariably used as the heap handle. When this value is passed to HeapMalloc, HeapCalloc, HeapRealloc, and HeapFree routines, each routine will correctly select the starting chunk and determine from which memory chain to carve or free the memory. To discard the heap, a new HeapRelease call is used that releases all the memory of the heap, (not individual memory blocks) back to the system.
Attempts have been made to deal with memory management without having to resort to expensive system calls at each instance. For example, in U.S. Pat. No. 5,339,411—Heaton, a method is disclosed in which the memory is allocated into a number of memory blocks of varying size at the time the memory space is initialized (usually during initialization of the application program). Then, in response to a memory allocation request during execution of the application, a routine is initiated that scans the stored block constants to locate a memory block of the appropriate size to meet the specifications of the allocation request. A mechanism is also provided that permits encroachment into a second adjacent memory block where no one memory block is large enough to meet the specifications of the memory allocation request. Other references, such as U.S. Pat. No. 5,088,036—Ellis, et. al. And U.S. Pat. No. 5,136,706—Courts propose methods for more efficient memory management through dividing the available memory space into regions with specific attributes so that only active objects are located in active regions, to reduce paging and other accessing operations.
Improved garbage collection, such as in the methods proposed in U.S. Pat. No. 4,907,151—Bartlett and U.S. Pat. No. 5,109,336—Guenther, et. al., is another way to maximize memory management efficiency in a predefined memory space.
In addition to the foregoing, U.S. Pat. No. 5,317,706—Pechter provides a hardware solution to increasing available virtual memory spacing in a processing environment through the addition of extended memory circuits. The extended memory is logically located or mapped to a portion of the original virtual address space which has been partitioned into a reduced virtual address space and an extended real memory address space.
However, none of the prior art methods proposed in the patent literature improve upon the traditional method for increasing heap memory allocation during program execution described above, that is through the routine allocation of additional memory instituted through system calls.
In addition, nothing in the prior art suggests a memory management system that actually permits the user to control the heap or type of heap in which the objects are to be constructed and controls the creation (allocation) and destruction (deallocation) of different heaps and different heap types.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide user control of multiple heaps in an operating system.
It is also an object of this invention to provide better performance of allocation and freeing operations within a heap, and to provide the user with the ability to free a single heap in one efficient operation while retaining data allocated in other heaps.
A further object is to provide less contention in multithreaded applications, by providing the user with the ability to allocate to each executing thread its own dedicated heap.
Accordingly, the present invention provides a mechanism for user heap management during program execution in an operating system that allocates dynamic memory. The mechanism consists of controls located in the executing program for directing heap allocation requests, preferably on data storage media adapted to be executed on a general purpose computer.
Preferably, in one aspect, the controls consist of executable steps for locating a block of heap memory of a suitable size for fulfilling the allocation request along executable steps for storing information in a portion of the heap memory defining parameters of the heap memory.
Preferably, in another aspect, the controls consist of executable steps for setting a default heap definition in the runtime library means.
The present invention also provides a process for managing heap allocation from a user application executing in an operating system to extend heap memory. The process includes the steps of issuing a callback function from the runtime library to the user application for a heap extension of at least the minimum size, determining if a block of memory of at least the minimum size is available, and removing
Benayon Jay William
Thomson Brian William
Bragdon Reginald G.
Duffield Edward H.
Flynn John D.
LandOfFree
User control of multiple memory heaps does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with User control of multiple memory heaps, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and User control of multiple memory heaps will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3288098