|Publication number||US6874062 B1|
|Application number||US 09/510,426|
|Publication date||Mar 29, 2005|
|Filing date||Feb 22, 2000|
|Priority date||Feb 22, 2000|
|Publication number||09510426, 510426, US 6874062 B1, US 6874062B1, US-B1-6874062, US6874062 B1, US6874062B1|
|Inventors||Richard A. Goldberg|
|Original Assignee||Unisys Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (10), Referenced by (26), Classifications (17), Legal Events (9)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates to an improved system and method for cataloging attributes assigned to an ordered group of searchable items; and more specifically, relates to an improved system and method that may be adapted for cataloging, locating, and allocating a set of N contiguous available storage sections of a storage facility within a data processing system.
Data processing systems typically include a finite amount of storage space. This storage space may be provided by a main memory comprised of Random Access Memory (RAM) devices. Data processing systems also generally include mass storage facilities provided, for example, by disk arrays.
The storage facilities within a data processing system must be managed so that appropriate space may be allocated in response to requests for such resources. For example, application programs may make requests for the allocation of temporary buffer space within the main memory. This buffer space may be needed as a scratch pad during program execution. Alternatively, the buffer space may be necessary to store data that is generated by the executing application. Such data may be stored in the main memory temporarily until it may be written to a mass storage facility, or may remain located in the memory on a more permanent basis.
Often, the memory allocation function is performed by an Operating System (OS). Application programs running under the control of the OS make requests to the OS for a portion of storage of a predetermined length. The OS locates the requested storage from the pool of system resources and assigns this storage space to the requesting application. When the application no longer requires the use of the storage space, it may be returned to the OS to be added back into the pool of available resources.
Sometime, the application programs themselves may also perform some of the memory allocation functions for the system. For example, the OS may provide an application with a block of available memory. The application controls the manner in which this block is allocated for use by the various tasks associated with the application.
Many mechanisms have been used to provide for the allocation of storage resources within a data processing system. According to one mechanism, a pool of buffers is created. Generally, all buffers in the pool will be the same size. This pool may be managed using many types of data structures. For example, the buffer addresses may be recorded using a linked list. When a request for storage is issued, the first address in the linked list may be provided to the requester. The address may then be removed from the linked list of available buffers and entered onto a different linked list of addresses associated with allocated resources, for instance. When the buffer is no longer required for use by the application, the buffer address is again moved to the list of available resources.
Use of the foregoing buffer pool approach provides a straight-forward mechanism for allocating storage. Assuming that a requested buffer is available for allocation, the storage may be performed with minimal delay. However, this approach may result in inefficient use of the storage space. This is because each buffer is generally of a same predetermined length. The buffer length is likely selected to satisfy the maximum memory requirement of the system. Requests associated with smaller storage requirements are satisfied using the standard-sized buffer. This results in wasted storage space, which may cause storage shortages in some systems.
An alternative approach to memory allocation addresses the above-mentioned problem by creating multiple buffer pools. Each pool provides a buffer of a different size. For example, a first pool may be associated with buffers that are each approximately 1000 bytes (1 Kbytes) in length, whereas a second pool may be associated with buffers that are each 1 million bytes (1 Mbytes) in length. Intermediate-sized buffers may also be provided by one or more additional buffer pools. A request for storage space is satisfied using the smallest buffer that is available and that can accommodate the request. If a buffer of the optimal size is not available to fulfill a request because a buffer pool has been depleted, a larger buffer from a different pool may be divided to create multiple smaller buffers which are then used to populate the depleted pool.
The use of multiple buffer pools allows storage resources to be allocated in a manner that conserves system resources. However, depending on the number of pools created within the system, more memory may still be allocated than is necessary. In the foregoing example in which buffers are only available in 1-Kbyte and 1-Mbyte sizes, a request for a buffer of 500 Kbytes must be satisfied using a 1 Mbyte buffer, which results in a considerable waste of storage space.
Another disadvantage associated with the foregoing buffer pool mechanisms involves the amount of storage space consumed by the data structures such as linked lists that are required to implement the buffer pools. Each entry in a linked list must include both an address pointer to the associated buffer, and must also contain at least one address pointer to another entry in the list. If the list is a doubly-linked list, two such address pointers to the linked entries are needed. Therefore, as the number of buffers in the data pool increases, the size of the linked list becomes prohibitive.
Another method for tracking and allocating available memory that is not associated with the above-described disadvantages involves the use of bitmaps. As is known in the art, a bitmap is a sequence of bits wherein each bit in the sequence is associated with a data item, a system resource, or whatever other type of entity is being described by this data structure. Generally, the bitmap is ordered, meaning the bits in the bitmap are arranged in a sequence indicative of the order in which the items being described are arranged. The state of a bit in the bitmap is indicative of an attribute that is associated with the data item being described.
A bitmap may be used to describe the availability of units of storage. In this case, a storage facility (or a portion thereof) is divided into sections that are all of the same predetermined length. Each bit in the bitmap is associated with a different respective one of the sections. The arrangement of the bits in the bitmap reflects the order of the sections within the storage facility. A bit may be set to a predetermined state to indicate whether or not the respectively associated storage section is available for allocation.
The use of a bitmap allows the size of an allocated buffer to closely approximate the size of the request. If smaller sections of storage space are utilized (for example, sections that are 1 K or 10 K bytes in length), wasted storage space is minimized. A contiguous number of available sections are allocated for those requests that require a buffer larger than a single section. Additionally, since only a single bit is required to describe whether each section of storage is allocated, a much smaller amount of memory is associated with the use of bitmaps as compared to the use of linked lists. The use of bitmaps in allocating storage resources allows requests to be satisfied with buffers that are sized more accurately to match a specific requirement. However, as a storage facility is divided into smaller sections, the bitmap size increases. For example, consider a portion of a storage facility that has been divided into sixteen million sections. The corresponding bitmap contains sixteen million (roughly 224) bits. Stated differently, the bitmap consumes roughly 2 Mbytes of memory. Performing a bit-by-bit search on this data structure to locate a contiguous number of N available sections can be time-consuming.
What is needed, therefore, is an improved system and method of tracking and cataloging the attributes associated with a set of ordered search items. This system and method allows a set of N contiguous items having a predetermined attribute to be located more efficiently than can be accomplished by performing a bit-by-bit search using a conventional bitmap structure. Such a method may be adapted for use in cataloging and allocating contiguous sections of available storage space as provided by a storage facility of a data processing system.
It is the primary object of the invention to provide an improved system and method for cataloging attributes associated with a set of ordered items being cataloged;
It is a further object to provide a hierarchical data structure adapted for use in locating a contiguous set of N items wherein every item in the set is associated with a predetermined attribute;
It is a further object of the invention to provide a system and method for locating available storage resources within a data processing system in a more efficient manner;
It is another object to provide a storage allocation system that utilizes a hierarchical data structure to record the availability of memory sections;
It is another object to provide a method of searching a hierarchical data structure describing storage availability within a data processing system in a manner that allows sections of the data structure indicative of allocated memory to be skipped;
It is yet another object to provide a method of storage allocation that provides enhanced performance in systems wherein a large percentage of memory is generally in use at any given point in time; and
It is a further object to provide an improved system and method for allocating storage in a more efficient manner in those systems that utilize a search that starts from a predetermined boundary of the storage address range.
Other more detailed objectives will become apparent from a consideration of the Drawings and the Detailed Description of the Preferred Embodiment.
The current invention provides an improved system and method for locating, within a group of ordered search items, a set of N contiguous ones of the items each having a desired attribute. This system and method is readily adapted for use in allocating contiguous sections of storage space within a data processing facility.
The system utilizes a hierarchical bitmap structure that includes multiple hierarchical BitMap Levels (BMLs). The Lowest-Level BML in the structure, also referred to as the LLB, is a bitmap wherein each bit corresponds to a different respective one of the search items, and the order of the bits is indicative of the order of the search items. Each bit is set to a state indicative of whether or not the respective one of the search items has been associated with a predetermined attribute. For example, when the LLB is adapted for use in a memory allocation system, each bit in the LLB corresponds to a different respective section of a storage facility. The arrangement of the bits within the LLB corresponds to the order the sections appear within the storage facility. Each bit is set to a predetermined state indicative of whether the respective section is available for allocation.
The LLB is divided into Segments, wherein each of the Segments includes multiple bits. In a first embodiment, each of the Segments has approximately the same number of bits as the other Segments, although the Segments need not be of equal length. A first hierarchical BML is defined to describe the Segments of the LLB. This first hierarchical BML is a bitmap wherein each of the included bits is associated with a different respective one of the Segments of the LLB. The arrangement of the bits in the BML corresponds to the LLB Segment order. A bit within the first BML is set to a predetermined state based on the collective states of the bits in the LLB. For example, a bit in the first BML may be cleared if any of the bits in the corresponding Segment is cleared. This may correspond to the situation in which at least one of the search items associated with the Segment is assigned the desired attribute.
The definition process is repeated for additional levels of hierarchy. For example, the first hierarchical BML is divided into Segments. A second BML is defined in the manner discussed above to describe the Segments of the first BML. That is, each bit in the second BML corresponds to a different respective one of the Segments of the first BML, and is set to a state indicative of the collective states of the bits in the respective Segment. This process may be repeated for any number of hierarchical levels in the hierarchical bitmap structure.
The above description can be further illustrated by returning to the current example. When adapted for use in a memory allocation system, each bit in the LLB corresponds to a section of storage. A bit may be set to a predetermined state, for example “0”, to indicate that the corresponding memory section is available for allocation. A first BML is then defined to describe this LLB. In one embodiment, a bit in the first BML is cleared to indicate memory availability if any of the bits in the corresponding Segment of the LLB is cleared, indicating memory availability. The other BML levels are defined in a similar manner.
The hierarchical structure may be used to efficiently locate any string of N contiguous items having the desired attribute. Returning again to the current example, assume that a storage buffer including four storage sections is required. A search may be performed on the hierarchical bitmap structure starting at one edge of the LLB. The search continues until four contiguous bits set to the predetermined state (that is, “0” in this example) are located. When the end of a Segment of the LLB is reached, the search proceeds to the next higher BML in the data structure. The search begins at this higher level with the bit within the higher-level bitmap that corresponds to the next LLB Segment that is to be searched. The search continues at this higher level until a bit is located indicating that at least one of the bits in the associated Segment is in the predetermined state indicating memory availability, or until the end of a Segment is reached. In the former case, the search proceeds to the respectively associated Segment at the next lower level in the bitmap to being a bit-by-bit search of this Segment. In the latter case, the search proceeds to the next higher level to be continued in the manner discussed above. In this manner, the bitmap is traversed efficiently by skipping any Segments wherein each bit in the Segment indicates that all associated data items do not have the desired search attribute.
A search is terminated if an edge of any BML is reached without locating the desired contiguous search items. In this case, the string of items is not available. Otherwise, the items are located, and the respectively associated bits in the LLB and in other BMLs must be set to a different state, if appropriate, to reflect a change of the attributes associated with the located search items. For example, if used in a memory allocation system, the bits in the LLB are set to a predetermined state to indicate the allocation of the corresponding memory sections. Similarly, bits within other BMLs may also have to be set to a different predetermined state as a result of the changes made to the LLB.
The foregoing example describes one method of using the hierarchical bitmap structure to locate N contiguous search items having a predetermined attribute. Another method is provided that utilizes a top-down search mechanism that may be better adapted to searches in which N is a relatively large number. According to this mechanism, each of the Segments within a particular BML must be the same size as the other Segments in that BML so that any bit within any BML represents the same number of search items as any other bit within the same BML.
According to the alternative process, the search for N contiguous search items having a predetermined attribute begins at one edge of the highest BML in the hierarchical structure. Within this highest BML, the search attempts to locate the minimum number of contiguous bits “X” required to represent N contiguous search items. For example, assuming a search item corresponds to a 1 Kbyte block of memory, and a buffer of 300 Kbytes is desired. Assume further that one bit in the highest BML represents 200 search items. Therefore, the search begins at the highest level by attempting to locate two contiguous bits representing the minimum 500 Kbytes required to accommodate the request.
When the desired number of bits are located, all bits corresponding to the located bits at the next lower BML in the hierarchy are located. The value “X” is reset to reflect the current BML. Then, within the string of located bits, the process is repeated to locate all combinations of X contiguous bits in the desired state within the current BML. The process is repeated in a recursive manner for all such located bit combinations until the LLB is reached. If the desired number of N contiguous search items having the desired attribute are not located by searching the LLB, X is reset to represent the highest BML. The process is repeated for the next set of X unprocessed bits within the highest BML.
The foregoing hierarchical bitmap structure allows searches for N contiguous items having a desired attribute to be completed more efficiently. This is because the bitmap may be traversed at a higher level in the bitmap hierarchy to skip those lower-level Segments that are not associated with any of the desired search items. The hierarchical bitmap structure is particularly effective in systems wherein, at any given point in time, a substantial percentage of memory is already allocated. The bitmap structure is also particularly adapted for those systems wherein searches for available storage space is always initiated from the same predetermined address boundary of the storage device. In both of these cases, large contiguous blocks of allocated memory may be efficiently skipped by moving to a higher level in the bitmap hierarchy to accomplish the search.
Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment and the drawings, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded to the extent of applicable law as illustrative in nature and not as restrictive.
In the system of the preferred embodiment, Files can further be subdivided into smaller addressable portions of memory called memory “sections”, wherein each section has a same predetermined size. For example, File B 206 is shown subdivided into Sections 208, 210, 212, and so on.
In the current system, the AP controls the allocation of Sections of a File. Sections are allocated whenever the AP requires buffer space to temporarily store data signals. AP allocates the appropriate number of contiguous memory Sections as are required to meet storage requirements at any given point in time. The Sections that are in use within a particular File will constantly fluctuate during AP execution. This may occur, for example, as Sections are newly allocated, or when data is written from a File to a Mass Storage Device 114, thereby freeing previously-used Sections for re-allocation. AP must record which Sections are in use within a File at any given point in time, so that available File space can be identified for future use.
In the preferred embodiment, AP records the allocation of File space using a bitmap scheme. According to this mechanism, each Section within a file is associated with a corresponding bit of a bitmap. The corresponding bit is set to a first state if the associated Section is available for use, and is set to the other binary state if the Section is already in use. This bitmap may be stored within a designated control area of Memory. For example, File A Control Structure 214 stores the bitmap for File A 204.
The use of a bitmap provides a straight-forward means of locating a contiguous area of available memory, as discussed above. A search of a bitmap is initiated at a predetermined edge of the data structure. The bits of the bitmap are searched in order until a predetermined number N contiguous bits are encountered that indicate the desired number of available memory sections. For example, assume AP 202 requires the use of a memory buffer that is larger than a single Section, but smaller than two Sections. AP may begin searching Bitmap 316 from the left edge of the data structure until the two contiguous bits 318 and 320 are encountered. These bits indicate that contiguous memory Sections 1 and 2 (labeled 302 and 304, respectively) may be allocated to satisfy the memory request. If, however, three contiguous Sections are required instead of two, none of the contiguous available portions of Memory 102 represented by
Although the bitmap implementation shown in
The above problem is addressed by the current invention, which provides a hierarchical bitmap structure. According to this system and method, a bitmap structure is defined that allows N contiguous search items to be located wherein all search items in the set have a same predetermined attribute. This system and method may be adapted for use in locating N contiguous sections of memory all having the same predetermined attribute. Namely, the contiguous sections are all available for allocation.
According to the current system, a hierarchical bitmap structure is defined to describe the first bitmap structure. Still another bitmap structure is used to describe the first hierarchical bitmap structure, and so on. At the highest level in the hierarchy, a bitmap data structure is defined that concisely represents the storage allocation patterns existing within an associated File. A recursive search may be used to traverse the various hierarchical levels in the bitmap to efficiently locate areas of contiguous memory that are available for allocation.
In a hierarchical bitmap scheme of the current invention, the Lowest Level Bitmap (LLB) in the hierarchy is the bitmap which has a one-to-one correspondence with Memory Sections. That is, the LLB contains a bit for each Section in a File. Such a bitmap structure is shown as Bitmap 316 of FIG. 3.
The LLB may be divided into Segments. According to one embodiment, these Segments all include a same predetermined number of bits. In a second embodiment, this is not a requirement, as will be discussed further below. A bitmap is then created to define the Segments of the LLB. This bitmap, which may be referred to as Bitmap 1, will include a corresponding bit to describe an associated different one of the Segments of the LLB. A bit will be in a first predetermined state if any of the bits in the corresponding LLB Segment are in the predetermined state indicating the availability of memory. In the current example, a bit in Bitmap 1 is set to “0” if any of the bits in the corresponding LLB Segment are also cleared. A bit in Bitmap 1 will be in the second state if all bits in the corresponding LLB Segment are in a state indicating the unavailability of memory. In the current example, a bit in Bitmap 1 is set to “1” if all bits in the corresponding LLB Segment are set.
In this example, Segment 406 describes nineteen Memory Sections that are all in use, as indicated by the fact that every bit in this bitmap Segment is set. Some of the Memory Sections described by bitmap Segments 402 and 404 are available for use, as indicated by the fact that some of the bits in these bitmap Segments are cleared.
Hierarchical Bitmap 1 500 may be used to shorten the time required to perform a search for an available portion of a File of a predetermined size. This can be accomplished since the Segments of the LLB that describe File Sections that are all in use as indicated by Bitmap 1 500 do not have to be searched on a bit-by-bit basis. This is best illustrated by example.
Assume that a search is being conducted to allocate memory for a buffer that is four contiguous Sections of Memory in length. This buffer is to be implemented within the predetermined File X. To find the available memory, a bitmap search is initiated on the hierarchical bitmap definition of File X as shown in FIG. 5. This search will begin at a predetermined edge of the LLB 400, which in the current example will be the left edge. The first bitmap Segment of the LLB, which is the Segment corresponding to bit 508 of Bitmap 1, and which is not illustrated in
If the edge of the Segment is reached without locating the desired memory, the search proceeds to the next higher level in the HBS, which is Bitmap 1 500. The next bit to process at this level is bit 509 in the current example, which corresponds to the next LLB Segment that is to be processed. Since this bit is cleared, indicating the availability of memory, the search continues with the next Segment of the LLB.
Assume that four contiguous available Sections of memory are not located, and the search proceeds to bit 502 of Bitmap 1. This bit is in the cleared state, and the search continues with the corresponding LLB Segment 402. Again, the right edge of this Segment is reached without locating the desired memory. Therefore the search proceeds from the LLB to Bit 504 of Bitmap 1 500 as exemplified by Arrow 510. The state of this bit again indicates the availability of some corresponding memory sections, and the search returns to corresponding Segment 404 of the LLB as indicated by Arrow 512. The search of this Segment is unsuccessful in that four contiguous cleared bits are not located. Processing continues with Bit 506 of Bitmap 1, as illustrated by Arrow 514. This bit is set, indicating that no search need be performed on corresponding LLB Segment 406. Bits 516 and 518 are also set, and the corresponding LLB Segments (not shown) are also not searched. The next LLB Segment to be searched will correspond to Bit 520, as indicated by Arrow 522.
The above example shows that by skipping portions of the LLB that are not associated with available memory, the search is completed more efficiently. The search will terminate when the desired memory is located, or when the edge of any of the levels in the HBS is reached without locating the memory.
Bitmap 1 of the current example has fewer bits than the LLB by a factor of nineteen. While this will reduce the search time, the search may still be prohibitively long if a File includes a large number of Sections. Therefore, additional hierarchical levels within the bitmap may be created in the manner described above. That is, Bitmap 1 may be subdivided into Segments. In some embodiments, each of the Segments includes a same predetermined number of bits, although in some implementations this is not a prerequisite, as will be discussed below.
Processing next continues with Step 710, in which the Current_BML is divided into a plurality of BitMap Segments (BMSs). In one embodiment, all BMSs within the same BML include the same number of bits, although this is not a requirement in some implementations, as will be discussed further below. In Step 712, another BML is defined to represent the Current_BML. The newly-defined BML includes a bit that represents a different associated one of the BMSs of the Current_BML. Each bit in the newly-defined BML is set to a state based on the states of the bits in the associated one of the BMSs. In the current embodiment, a bit is cleared within the newly-defined BML if any bit in the associated one of the BMSs is cleared, and is set if all bits in the associated one of the BMSs is set. In Step 714, the Current_BML is set to the newly-defined BML. In Step 716, it is determined whether the Current_BML includes fewer than a predetermined number of bits. If this condition is met, the definition process is completed, as shown by Step 718. Otherwise, the process is continued with Step 710, as illustrated by Arrow 720. Thus, the process continues until the highest level BML is as small as is desired by the user. In the preferred embodiment, the definition process is considered complete when the highest level BML is small enough to fit within one addressable storage location of the memory.
Several search mechanisms may be employed to utilize the HBS that is defined using the process of FIG. 7. In either instance, the HBS may be used to locate an available storage Segment of a predetermined length in a manner that is more efficient that performing a bit-by-bit search of a conventional bitmap data structure.
The process of
At the end of each Segment search, whether at the LLB or another higher level in the HBS, the search proceeds to the bit in the next higher level in the HBS that corresponds to the next Segment to search in the previous (lower) level. If this bit at the next higher BML is not located within the same Segment as the Segment most-recently processed within that next higher BML, the search must again proceed to the next higher level in the bitmap. As the search proceeds at any level other than the LLB, a bit indicating the availability of memory causes the search to continue within the corresponding bitmap Segment residing at the next lower level in the HBS. A bit indicating the unavailability of memory is skipped such that the search proceeds at the then current bitmap level.
The process of
Next, processing continues at Step 802. If the Current_Bit is set to a predetermined state indicating the availability of portions of the memory associated with that Current_Bit, processing continues at Step 804, as indicated by Arrow 806. In Step 804, it is determined whether the Current_BML is the LLB. If it is, the value stored in variable “Count” is incremented by one, indicating that an available section of memory has been located. This is shown in Step 808. Next, it is determined whether the Count has reached a predetermined value indicating the requisite amount of available memory has been located, as shown by Step 810. If Count is set to this predetermined value, the bits in the LLB which resulted in the Count incrementation are set to the predetermined state to represent that the corresponding memory Sections have been allocated. Additionally, all other bits at any level in the HBS associated with the allocated memory must be set to an appropriate state to indicate whether these bits correspond to a memory portion that has been completely allocated. This is shown in Step 812. In Step 814, processing is completed, and the memory address associated with the located available memory sections may be returned to the requester.
If the Count has not reached the predetermined value in Step 810, processing continues with Step 818 (
Returning to Step 804 of
Considering Step 802 again of
The alternative search mechanism for N contiguous available memory sections is shown in detail in FIG. 9. The search starts at one edge of the highest level in the HBS. The search looks for as many contiguous bits in the predetermined state as are required to satisfy the buffer requirements. In other words, assume each bit at the highest level represents one-half megabytes of memory. The desired buffer is 750,000 bytes. The search therefore looks for two consecutive bits that are in the state which indicates the presence of available memory. When these bits are found, the search proceeds to the next lower lever in the hierarchy. All bits at this lower level that correspond to the previously-located bits are searched to determine if any combination of consecutive ones of these corresponding bits indicate the possibility of an available buffer of the necessary size. For each located combination of bits, the search proceeds to the next lower level in a recursive manner. If no combination of bits is located, the search proceeds once again by incrementing the current bit number and continuing at the highest level in the HBS. The steps of this search are shown in detail in FIG. 9.
The process of
Returning to Step 910, if no address is returned after the call to Find_Memory, execution proceeds to Step 918, as shown by Arrow 920. In this Step it is determined whether there are any more bits to process within the highest level of the HBS. If so, the Current_Bit is incremented to describe the bit that is adjacent to the previous Current_Bit. This is illustrated by Step 922. Execution continues with Step 902, as indicated by Arrow 924. If no additional bits remain in the highest level of the HBS, processing is completed without locating the desired available memory. This is shown by Arrow 925 and Step 926.
Returning again to Step 902, if the Current_Bit and all (X−1) bits next to the Current_Bit in the Current_BML are not each set to the predetermined value indicating available memory, processing continues to Step 918, as shown by Arrow 907. From Step 918 processing proceeds in the manner discussed above.
In Step 932, it is determined whether within the current set of bits located in Step 930 there exists a contiguous string of N bits wherein each bit in the string is set to the predetermined state indicating available memory. If no such string is located, processing is completed, and a return to the calling set of instructions is executed. This is indicated by Step 937 and Arrow 934. If such a string is located, processing continues with Step 935. In Step 935, a description of a selected one of the contiguous located strings of bits is saved in Saved_Bits. In Step 936, the routine Find_Memory is called recursively. If an address is returned indicating that the desired available memory had been located, each of the bits in the Current_BML that corresponds to a bit described by Saved_Bits must be set to an appropriate state. This state indicates whether or not the bit corresponds to memory that has been entirely allocated. This is illustrated by Steps 938 and 939, respectively. Then the memory address which was returned by Find_Memory is returned to the calling set of instructions, as shown in Step 940.
If an address is not returned by Find_Memory, processing continues with Step 942, as shown by Arrow 943. If any additional strings of bits located in Step 932 remain to be processed, execution proceeds to Step 935, as indicated by Arrow 941. If all strings of bits have been processed without locating an available Segment of memory of the desired length, a return to the calling set of instructions is executed, as shown in Step 937.
Returning now to decision Step 931 (FIG. 9B), if the current BML is the LLB, processing proceeds to Step 942 (FIG. 9C), as indicated by Arrow 944. In this Step, a determination is made as to whether a contiguous group of N bits is set to the predetermined state indicating available memory. If so, the bits are set to the state indicating the memory is now unavailable, as illustrated by Step 946. The address of the memory buffer corresponding to the located bits is returned to the calling set of instructions, as indicated by Step 948. Otherwise, if no set of bits may be located indicating the availability of the desired memory, a return to the calling set of instructions is executed as indicated by Step 950 and Arrow 952.
The processes of
In the current example, Level Descriptor 1006 for the LLB bitmap includes a starting memory address and the bit-length of the LLB portion of Bitmap Packet 1002. The Level Packet may be used by the various methods described above to access the HBS embodied within the Bitmap Packet 1002.
Although the above description discusses the HBS as being employed by an Application Program to allocate memory, it will be understood that such a process could be employed by any memory management facility, including a memory management process running within an Operating System. Furthermore, this system and method is not limited to implementations wherein Sections of Files are being allocated, but may be used to manage any units of storage, and may be applied to allocation of both main memory areas or Segments of mass storage devices. Finally, although the implementation discussed above describes the invention in the context of a memory allocation system, this system may be adapted for use in locating any N contiguous search items wherein each of the N items is associated with a given desired attribute.
In view of the detailed descriptions and drawings, various modifications or implementations will become apparent to those skilled in the art without departing from the spirit and scope of the invention, and what is described to be protected by Letters Patent is set forth in the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5713002 *||Oct 13, 1995||Jan 27, 1998||Microsoft Corporation||Modified buddy system for managing storage space|
|US5802599 *||Jul 30, 1996||Sep 1, 1998||International Business Machines Corporation||System and method for allocating storage in a fragmented storage space|
|US5829004 *||May 20, 1996||Oct 27, 1998||Au; Lawrence||Device for storage and retrieval of compact contiguous tree index records|
|US5873118 *||Sep 1, 1994||Feb 16, 1999||Microsoft Corporation||Method and system for storing file system state information in multiple sectors based on update frequency|
|US6115716 *||Sep 3, 1999||Sep 5, 2000||Nokia Telecommunications Oy||Method for implementing an associative memory based on a digital trie structure|
|US6175900 *||Feb 9, 1998||Jan 16, 2001||Microsoft Corporation||Hierarchical bitmap-based memory manager|
|US6185663 *||Jun 15, 1998||Feb 6, 2001||Compaq Computer Corporation||Computer method and apparatus for file system block allocation with multiple redo|
|US6453403 *||May 19, 2000||Sep 17, 2002||Sun Microsystems, Inc.||System and method for memory management using contiguous fixed-size blocks|
|US6510505 *||May 9, 2001||Jan 21, 2003||International Business Machines Corporation||System and method for allocating storage space using bit-parallel search of bitmap|
|US6560610 *||Aug 10, 1999||May 6, 2003||Washington University||Data structure using a tree bitmap and method for rapid classification of data in a database|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7487424 *||Feb 10, 2006||Feb 3, 2009||Samsung Electronics Co., Ltd.||Bitmap manager, method of allocating a bitmap memory, method of generating an acknowledgement between network entities, and network entity implementing the same|
|US7685181||Feb 26, 2007||Mar 23, 2010||International Business Machines Corporation||Method and system for utilizing a hierarchical bitmap structure to provide a fast and reliable mechanism to represent large deleted data sets in relational databases|
|US7689630 *||Mar 30, 2010||Richard L. Lam||Two-level bitmap structure for bit compression and data management|
|US7859703 *||Apr 10, 2006||Dec 28, 2010||Konica Minolta Business Technologies, Inc.||Image forming apparatus, image forming method and recording medium having program recorded thereon|
|US7904618 *||May 31, 2006||Mar 8, 2011||Sony Computer Entertainment Inc.||Buffer managing method and buffer managing apparatus|
|US7937535 *||Feb 22, 2007||May 3, 2011||Arm Limited||Managing cache coherency in a data processing apparatus|
|US8095548||Oct 14, 2008||Jan 10, 2012||Saudi Arabian Oil Company||Methods, program product, and system of data management having container approximation indexing|
|US8099556||Sep 13, 2005||Jan 17, 2012||Arm Limited||Cache miss detection in a data processing apparatus|
|US8185724||Mar 3, 2006||May 22, 2012||Arm Limited||Monitoring values of signals within an integrated circuit|
|US8281103 *||Feb 9, 2010||Oct 2, 2012||Huawei Technologies Co., Ltd.||Method and apparatus for allocating storage addresses|
|US9176963||Oct 30, 2008||Nov 3, 2015||Hewlett-Packard Development Company, L.P.||Managing counters in a distributed file system|
|US9218135||Jun 16, 2010||Dec 22, 2015||Microsoft Technology Licensing, Llc||Hierarchical allocation for file system storage device|
|US20040186967 *||Dec 3, 2003||Sep 23, 2004||Anupam Anand||Free pointer pool implementation|
|US20060195753 *||Feb 10, 2006||Aug 31, 2006||Samsung Electronics Co., Ltd.||Bitmap manager, method of allocating a bitmap memory, method of generating an acknowledgement between network entities, and network entity implementing the same|
|US20070146785 *||Apr 10, 2006||Jun 28, 2007||Konica Minolta Business Technologies, Inc.||Image forming apparatus, image forming method and recording medium having program recorded thereon|
|US20080209133 *||Feb 22, 2007||Aug 28, 2008||Arm Limited||Managing cache coherency in a data processing apparatus|
|US20090031082 *||Mar 6, 2006||Jan 29, 2009||Simon Andrew Ford||Accessing a Cache in a Data Processing Apparatus|
|US20090043927 *||May 31, 2006||Feb 12, 2009||Sony Computer Entertainment Inc.||Buffer managing method and buffer managing apparatus|
|US20090043993 *||Mar 3, 2006||Feb 12, 2009||Simon Andrew Ford||Monitoring Values of Signals within an Integrated Circuit|
|US20090222625 *||Sep 13, 2005||Sep 3, 2009||Mrinmoy Ghosh||Cache miss detection in a data processing apparatus|
|US20100115009 *||Oct 30, 2008||May 6, 2010||Callahan Michael J||Managing Counters in a Distributed File System|
|US20100169322 *||Dec 26, 2008||Jul 1, 2010||Sun Microsystems, Inc.||Efficient access of bitmap array with huge usage variance along linear fashion, using pointers|
|US20100211755 *||Aug 19, 2010||Huawei Technologies Co., Ltd.||Method and apparatus for allocating storage addresses|
|CN102934094A *||Jun 3, 2011||Feb 13, 2013||微软公司||Hierarchical allocation for file system storage device|
|CN102934094B *||Jun 3, 2011||Dec 3, 2014||微软公司||Hierarchical allocation for file system storage device|
|EP1816848A1||Oct 2, 2006||Aug 8, 2007||Konica Minolta Business Technologies, Inc.||Freeing of memory areas in an image forming apparatus|
|U.S. Classification||711/117, 711/E12.006, 711/173, 707/999.003|
|International Classification||G06F12/02, G06F3/06|
|Cooperative Classification||Y10S707/99933, G06F3/064, G06F3/0656, G06F12/023, G06F3/0689, G06F3/0613|
|European Classification||G06F3/06A6L4R, G06F3/06A4T2, G06F3/06A2P4, G06F3/06A4F2, G06F12/02D2|
|Feb 22, 2000||AS||Assignment|
Owner name: UNISYS CORPORATION, MINNESOTA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GOLDBERG, RICHARD A.;REEL/FRAME:010627/0266
Effective date: 20000216
|Jun 20, 2006||AS||Assignment|
Owner name: CITIBANK, N.A., NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNORS:UNISYS CORPORATION;UNISYS HOLDING CORPORATION;REEL/FRAME:018003/0001
Effective date: 20060531
Owner name: CITIBANK, N.A.,NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNORS:UNISYS CORPORATION;UNISYS HOLDING CORPORATION;REEL/FRAME:018003/0001
Effective date: 20060531
|Aug 19, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Oct 12, 2009||AS||Assignment|
Owner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERA
Free format text: PATENT SECURITY AGREEMENT (PRIORITY LIEN);ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:023355/0001
Effective date: 20090731
|Oct 13, 2009||AS||Assignment|
Owner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERA
Free format text: PATENT SECURITY AGREEMENT (JUNIOR LIEN);ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:023364/0098
Effective date: 20090731
|Jun 27, 2011||AS||Assignment|
Owner name: GENERAL ELECTRIC CAPITAL CORPORATION, AS AGENT, IL
Free format text: SECURITY AGREEMENT;ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:026509/0001
Effective date: 20110623
|Oct 1, 2012||FPAY||Fee payment|
Year of fee payment: 8
|Mar 15, 2013||AS||Assignment|
Owner name: UNISYS CORPORATION, PENNSYLVANIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY;REEL/FRAME:030004/0619
Effective date: 20121127
|Mar 26, 2013||AS||Assignment|
Owner name: UNISYS CORPORATION, PENNSYLVANIA
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERAL TRUSTEE;REEL/FRAME:030082/0545
Effective date: 20121127