Abstract:
A method of managing a fixed length memory block pool having a plurality of memory blocks includes receiving a memory block address from a memory management module, in which the memory block address corresponds to an available memory block. The method further includes decrementing the memory block address by an amount substantially equal to a size of the overhead area of the available memory block.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention is directed to memory in computer systems. More particularly, the present invention is directed to management of fixed length memory block pools.  
         BACKGROUND INFORMATION  
         [0002]    A typical computer system includes a processor, operating system, and memory. The memory typically includes banks of random access memory (“RAM”), read only memory (“ROM”), and hard drive storage. Most systems also include software or firmware to efficiently manage dynamic use of some of the memory, especially the RAM.  
           [0003]    Memory in many computer systems is allocated in fixed-length blocks, to avoid issues of memory fragmentation and garbage collection. However, using fixed-length blocks requires that some memory be set aside to track which blocks have been allocated and which have not. The set aside memory is overhead and cannot be used for ordinary tasks, and thus reduces the amount of memory available for the computer system.  
           [0004]    Based on the foregoing, there is a need for a method of managing memory that does not require some memory to be set aside, thus reducing overhead. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0005]    [0005]FIG. 1 is a block diagram illustrating a prior art memory management module for efficiently managing dynamic memory use.  
         [0006]    [0006]FIG. 2 is a block diagram illustrating how a prior art memory management module interfaces with a software application to allow the application the use of a memory block.  
         [0007]    [0007]FIG. 3 is a block diagram and flowchart illustrating steps performed by one embodiment of the present invention when an application requests a memory block.  
         [0008]    [0008]FIG. 4 is a block diagram and flowchart illustrating steps performed by one embodiment of the present invention when the application releases a memory block.  
         [0009]    [0009]FIG. 5 is a block diagram illustrating the block pool after the memory management module receives the block pointer address from the present invention.  
         [0010]    [0010]FIG. 6 is a block diagram of a computer system that can implement the present invention.  
     
    
     DETAILED DESCRIPTION  
       [0011]    One embodiment of the present invention is a method of adding a layer of memory management firmware or software between a software application and existing memory management firmware, also referred to as a “memory management module”, to eliminate the overhead typically required by memory management schemes.  
         [0012]    [0012]FIG. 1 is a block diagram illustrating a prior art memory management scheme or module for efficiently managing dynamic memory use. The memory management module is typically part of an operating system implemented by a computer.  
         [0013]    A block pool is shown in FIG. 1 that includes fixed length memory blocks  100 ,  110  and  120 . The block pool may be formed from the RAM of a computer system. The computer system may also include other block pools that have fixed lengths that differ from the lengths of memory blocks  110 ,  110  and  120 .  
         [0014]    Each memory block has a section for storing data, and a section for storing information used by the operating system kernel to manage the use of the block. This latter section, referred to as the “overhead section”, is not available to a software application for storing data. For example, block  100  has an overhead section  102  and a data section  104 , block  110  has an overhead section  112  and a data section  114 , and block  120  has an overhead section  122  and a data section  124 . In one embodiment, eight bytes of each memory block is dedicated to the overhead section.  
         [0015]    In operation, block  100  is the first block of a chain of blocks that form the block pool. An available list pointer  108  points to the first byte (i.e., byte  0000  of block  100 ) of the first block in the chain. Stored in overhead section  102  of first block  100  is the first address of the next available block (i.e., byte  0030  of block  110 ). Stored in overhead section  112  of the next available block  110  is the first address of the next available block (i.e., byte  0090  of block  120 ), and so on. Therefore, all of the available blocks are linked together and the address of the next available block can be returned to an application when it is requested.  
         [0016]    [0016]FIG. 2 is a block diagram illustrating how a prior art memory management module interfaces with a software application to allow the application the use of a memory block. When the application requests a memory block, the memory management module determines the first available memory block from the available list pointer  108  shown in FIG. 1. In the example of FIG. 2, block  100  is the first available memory block. The memory management module then returns address  0008  of block  100  to the application, since the first 8 bytes (i.e., addresses  0000 - 0007 ) are reserved for overhead. The memory management module then places a pool pointer in overhead area  102 . The pool pointer identifies the block pool that block  100  is part of. Each block pool has a unique identifier. Available list pointer  108  is then pointed to address  0030  of block  110 , since block  110  is now the next available block of the block pool.  
         [0017]    One example of an operating system that implements the memory management module described above in conjunction with FIGS. 1 and 2 is the ThreadX Real-Time Operating System available from Green Hills Software Inc.  
         [0018]    One embodiment of the present invention interfaces with the memory management module in the prior art operating system described above to allow the overhead area of the blocks to be utilized for storage by applications. FIG. 3 is a block diagram and flowchart illustrating steps performed by one embodiment of the present invention when an application requests a memory block. Initially, the present invention receives address  0008  from the memory management module, as described above in FIG. 2. The present invention then decrements the address by the overhead length (i.e., 8 bytes) at step  200 . At step  210 , the decremented address,  0000 , is returned to the application. The entire block  100 , including overhead area  102 , is now available to the application. The pool pointer, which is written in overhead area  102  as described in FIG. 2, is overwritten by the application because the application is storing information in overhead area  102 .  
         [0019]    [0019]FIG. 4 is a block diagram and flowchart illustrating steps performed by one embodiment of the present invention when the application releases memory block  100 . At step  230 , the pool pointer is restored to overhead area  102 . At step  240 , the present invention increments the block pointer address by the length of overhead area  102  (i.e., 8 bytes). The memory management module receives block pointer address of  0008  from the present invention.  
         [0020]    [0020]FIG. 5 is a block diagram illustrating the block pool after the memory management module receives the block pointer address from the present invention. The memory management module retrieves the pool pointer from overhead area  102  and determines the next available block in the block pool that is identified by the pool pointer. The address of the next available block (i.e.,  0030 ) is then written in overhead area  102  of block  100 , thus overwriting the pool pointer. Block  100  is now available for storage needs of an application.  
         [0021]    [0021]FIG. 6 is a block diagram of a computer system  600  that can implement the present invention. Computer system  600  includes a processor  610 , memory  620  and a bus  615 . Processor  610  can be any type of general purpose processor. Memory  620  can include RAM, ROM and hard drive memory, or any other computer readable medium. Memory  620  includes instructions that, when implemented by processor  610 , function as an operating system and instructions that implement the present invention. In one embodiment, the operating system is the ThreadX operating system. The steps performed by the present invention can be performed by software, hardware, or any combination of both.  
         [0022]    As described, one embodiment of the present invention interfaces with the prior art memory management module to allow overhead areas of memory blocks to be utilized for storage by applications. This increases the amount of memory available to applications in a given block pool.  
         [0023]    Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.