CA2119788C - Computer method and system for allocating and freeing memory - Google Patents
Computer method and system for allocating and freeing memoryInfo
- Publication number
- CA2119788C CA2119788C CA002119788A CA2119788A CA2119788C CA 2119788 C CA2119788 C CA 2119788C CA 002119788 A CA002119788 A CA 002119788A CA 2119788 A CA2119788 A CA 2119788A CA 2119788 C CA2119788 C CA 2119788C
- Authority
- CA
- Canada
- Prior art keywords
- block
- free
- list
- size
- segment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
Abstract
A method and system for allocating and freeing memory is pro-vided. In a preferred embodiment, a requesting program running on a computer system allocates a logically contiguous block of memory (a "heap") for the temporary storage of data structures. A Heap Manag-er, provided by the present invention, manages the heap in response to requests from the requesting program. The Heap Manager allocates and frees blocks within the heap. The Heap Manager logically divides the heap into segments and maintains a free list for each segment. The free list is a list of the free blocks contained in a segment. The heap has an associated free block array and an associated size tree. The free block array has a plurality of entries; each entry points to a free list for a segment. Each leaf node of the size tree corresponds to a plurali-ty of entries in the free block array. A value contained in each leaf node indicates the size of the largest free block in the segments corre-sponding to the plurality of entries. The size tree is arranged in such a way that the value of each node is equal to the largest value of its child nodes. The Heap Manager selects a free block for allocation to the re-questing program by searching the size tree and the free block array and selecting a segment that contains a free block that will satisfy the request, and then searching the free list corresponding to the selected segment to locate the smallest free block that satisfies the request. The Heap Manager frees a block in a segment by updating the free list for the segment, the free block array entry that points to the free list, and the size tree.
Description
~ WO 94/02898 PCr/US93/07021 2 ~ 1 ~7~3 Descriotion C~.~u ~ ~;~ METE[OD AND SYSTEM ~OR
ALLOCATING AND FREEI~G ~EMORY
TPrhn i CA ~ Field This invention relates generally to a computer method and system for memory -~n5-, L, and, more 10 particularly, to a method and system for allocating, ~reeing, and compacting memory that uses a heap structure.
Bach~lL u~ of the Tnvention A computer system may manage computer memory 15 dynamically. Dynamic memory management refers to the process by which blocks of memory are allocated temporarily rOr a SpPri f i r purpose and then ~ rated or freed when no longer needed ~or that purpose. Free blocks are available ~or reallocation for another purpose. The 20 process that dyn~ir~l ly manages memory is referred to as the memory manager. The memory that the memory manager manages is referred to as a "heap. " A heap is a portion of memory 1-3S~LV-:d for a program to use for the temporary storage of data structures whose existence or size cannot 25 be de~Prm; nPd until the ~~~gram is running . The program can request a block of free memory having a certain size, use it, and later request that the block be freed. The memory manager allocates dif~erently sized blocks of memory from the heap according to the needs of the 3 0 requesting program .
When a program needs a blocX of memory, the program sends a re~uest to the memory manager. The memory manager allocates a block of memory from the heap to satisfy the request and then sends a handle or pointer to 3 5 the block o~ memory back to the res~uesting program . The re~uesting program can then access the block of memory through the handle or pointer. When the requ sting _ _ _ _ _ _ _ _ _ _ _ _ . ... ...
WO 94/02898 PClr/US~3/07021~
z~ l9788 2 program is rinished using the block o~ memory, the program notif ies the memory manager that the block is no lonqer needed. The memory manager then frees the block of memory to make the block available rOr allocation. When the 5 memory manager cannot allocate a block of memory to a requesting program (because the heap does not contain a large enough block), the memory manager usually compacts the heap to consolidate all of the free blocks.
lO S rv of the Invention It is an object of the present invention to provide an ; ~ve:d memory management process for a computer memory.
It is another obj ect of the present invention to 15 provide an i .,v~:d method of allocating a block of memory to a requesting program.
It is another object of the present invention to provide an improved method of freeing a block of memory when the memory is no longer needed by a requesting 2 0 program .
It is yet another obj ect of the present invention to provide an i ~Jved method of compacting memory .
These and other objects, which will become 25 apparent as the invention is more fully described below, are obtained by an improved method and system for dynamic memory management. In a pre~erred PT~hOA i~ L, a requesting program running on a computer system allocates ~ contiguous block of memory (a "heap") for the temporary 3 0 storage o~ data structures . A Heap Nanager, provided by the present invention, manages the heap in response to instructions from the requesting program. The Heap Nanager divides the heap into 2n segments having unif orm size. The Heap Nanaqer allocates blocks of memory to the 35 requesting program. When the requesting program is ~ ;n; -:h.Q~ using a block of memory, the E~eap Manager frees . .
. . ~
WO 94/02898 PCl`/US93~07D21 ~ ~97~8 the block of memory so that the block of memory can be allocated .
In a preferred ~mho~;- L, the Heap Manager maintains a free list for each segment, which is a linked list of the free blocks beginning in that seg_ent. Each ~ree list is ~rr~cs;hle through a maximum free block array and a size tree. The maximum free block array has a plurality o~ entries; each entry .ULL_a~UUI~dS to a segment and points to the boq; nn; ng of the free list ~or the segment. The size tree is a complete binary tree, arranged in such a way that the value of each node is equal to the largest value of its child nodes. Each leaf node of the size tree ~ urLo,~ùl~-ls to two entries in the maximum free block array. The value contained in each leaf node indicates the size of the largest ~ree block in the s~ L~ CC)LL_ ~u~ ;nrJ to two entries in the free block array.
The Heap Manager allocates a block of memory to a requesting program by selecting a free block of memory o~ a requested size from the heap. The Heap Manager selects the free block by searching the size tree and free block array and selecting a segment that c~-nt:-; nC a free block that will satisfy the request, and then searching the free list CuLL~ ;ng to the selected segment to locate the smallest free block that satisfies the request.
The Heap Nanager frees a block of memory at the request of a requesting program and consolidates the ~reed block with any free blocks that may be located immediately above or below the freed block.
When the Heap Manager cannot satisfy an allocation request, the Heap Manager makes an out of memory call, which gives the requesting program the option of compacting the heap, or allocating the heap to a larger or smaller size. The Heap Manager ~ -~tc the heap by moving the allocated blocks to higher addresses in the heap, thereby consolidating the free blocks at the lower addresses. The Heap Manager optionally maintains handles WO 94~02898 PCr/US93/07021 to the allocatad blocks to keep track of where they are moved. ~ihen the requesting program provides a call back routine, the Heap Nanager invokes the call back return to notify the requesting progra~ when an allocated block is S going to be moved so that the requesting program can update any pointers Lt has to the allocated block.
Brief Descri~tion of t~h~e Drawinqs Figure 1 is a schematic diagram showing the 10 relarinnch;~ between a requesting program, the Eleap Manager, and the heap.
Figure 2A is a sample segment layout of the block 2rea referred to in Figure 1.
Figure 2B is a sample block layout of the block 15 area referred to in Figure 2A.
Figure 3 is a schematic diagram showing the relation~h;r between the control area and a portion of the block area.
Figure 4 is a detailed ~low diagram of a method 20 used by the present invention to allocate a data block to a requesting program.
Figures 5A-B are detailed ~low diagrams of a method used by the present invention to free a data block at the request of a requesting program.
Figures 6A-B are detailed flow diagrams of a method used by the present invention to compact the heap.
Figure 7A is a sc_ematic diagram of the size tree, maximum free block array, data block area and handle block bef ore compaction .
Figure 7B is a schematic diagram of the size tree, maximum free block array, data block area, master block, and handle block after _ ~-t-; nn, Detailed Descrir~tion o~ ~he Invention The present invention provides a method and system ~or dyn2mic memory management of a heap. A heap is a logically contiguous area of memory used by a requesting , ~
~ WO 94~02898 PCI~/US93/07021 program for the temporary storage of data ~LLU~.~U~=S. A
program called the Heap ~anager responds to service requests made by a requesting program running on a computer system. The service requests include allocating, 5 freeing, and compacting memory space within the heap.
Figure 1 is a schematic diagram showing the relarionch;~
between the requesting program 100, the Heap ~an~ger lol, and the heap 10 5 .
In a preferred ,~mho~i -nt, a memory manager 10 maintains various data structures within the heap.
Referring to Figure 1, in a preferred ~ o~i ~ of the present invention, a heap 105 is divided into three major areas: header area 102 which holds control inf ormation;
block area 103 which contains blocXs of memory that are 15 allocated ana freed upon request; and control area 104 which contains control information. Header area 102 is physically located below block area 103, which is physically located below control area 104. When referring to locations within the heap, "below" means at a lower 20 memory address, while "above" means at a hiyher memory address. Alternatively, header area 102 and control area 104 are not physically located next to block area 103.
Header area 102 contains control information, such as the size of the heap and pointers to ~Luu~uLes in 25 control area 104 and to speci~ic blocks within block area 103. Block area 103 is divided into segments. A segment is a logically contiguous area of memory used by the Heap Manager in maintaining lists of free blocks. The division of }~lock area 103 into segments is described in more 30 detail below. Block area 103 is also divided into blocks.
A block i5 a logically contiguous area of memory which is allocated and freed by the Heap Manager at the request of a re~uesting program.
Each block in block area 103 begins with a size 35 field which indicates the size of the block. Block sizes are preferably even numbers because the low-order bit of the size field is used to indicate whether the block is .. , _ . _, _ . , . ., ,,,,, . . , .... , _ _ , _ _ _ _ _ . _ _, .
WO 94/02898 PCltUS93/07021~
` 2i ~ 97~ ` 6 free. A free block has the low-order bit of the size field set while an allocated block has this hit clear.
All free blocks within a segment are linked together to rorm a rree list ~or that segment. Each free block contains a pointer, pre~erably located after the size f ield, to the next smaller ~ree block that starts in the same segment. Thus, each segment has a ~.u, r-~v-.ding free list which is a linked list (accordinq to size) of free blocks in that segment . The last f ield of each block is used as a free hint field. The free hint field is set to a unique signature value ir the block is free. The free hint f ield is used when freeing a block to aid in de D~m;n;ng whether the freed block is adjacent to a free block. If so, the rreed block is combined with the I5 adjacent free block to form one rree block.
Control area 104 comprises a maximum frQe block array and a size tree. The maximum free block array is a list that contains one entry for each segment. Each entry in the maYimUm ~ree block array points to the beginning of the free list for the segment that cu~ yvllds to the entry. As described above, the free list for each segment is a linked list of free blocks in the segment according to size, such that the largest free block in the segment is the beginning of the free list.
The size tree is a data structure that comprises nodes that are linked together in a hierarchical f ashion .
The nodes contain values ~ s~.i.ing the size of the largest free block in each subtree. The topmost node is called the root node. The root node has two child nodes and the root node is the parent node to its child nodes.
Each child node in the size tree has two child nodes of its own. Every node in the size tree has exactly one parent node, except for the root node, which has none. A
node that has no child nodes is called a leaf node. The size tree is a complete binary tree with the ~J.U~eL ~y that the value contained in any node is equal to the larger of the values contained in either of its child nodes. The . . ~
~ WO 94/02898 PCr/US93tO7021 7 2 ~ 1 97g8 size tree is preferably oryanized so that each child node is positioned at locations 2N and 2N+l for a parent node N. The size tree organizes the segments based on the size cf the largest free block in each segment. The size tree 5 contains N-1 nodes where N is e~ual to the number of s_, ~~ L:, in the block area . Each node of the size tree contains the size of the largest free block available in its subtree, so that the root node contains the size of the largest free block in the heap. Each leaf node of the 10 size tree ,UL' ~ Ul-dS to two entries in the maximum free block array such that the leaf node contains the size of the largest free block pointed to by the CULL~-1J~ ng entries in the maximum free block array.
The block area is divided into 2n sl, ~:, to 15 uuLL~u~ld with the size tree being a complete binary tree . In a pref erred embodiment, during heap initialization the Heap Manager determines the number of 8 ~, Ls by dividing the size of block area 103 by a minimum segment size and then rounding the result to the 20 next lower power of two. The minimum segment size (as specified by the re~uesting program) is an arbitrary value, commonly 1000 - 2000 bytes, based on the needs of the requesting program. The final segment size is de~Prm; nPd by dividing the size of block area 103 by the 25 number of s- L~;.
For example, i~ block area 103 contains 900 bytes and the minimum segment size is 100 bytes, then the ~eap Manager detPrminPc the final segment size as follows.
First, the Heap Manager divides the size of block area 103 30 by the minimum segment size, which results in 9 (900/100).
Second, the Heap Manager rounds the result to the next lower power of two to ~a~P~; nP the number of segments.
Nine rounded down to the next lower power of two results in 8 segments. Last, the Heap Manager divides the size of 35 block area 103 (900) by the number of segments (8) to determine the final segment size, which is 113 bytes (900/8). The last segment is only 109 bytes because the .. . ... . . . . .. . . . . _ .. .. _ . . ... _ _ WO 94/02898 _ PCr/US93/07021 21 ~ 97 88 8 number of segments Ln this example does not divide evenly Lnto the size of the block area. Figure 2A is a &le segment layout of block area 103 having ~ segments 200-207 .
Figure 2B is a sample block layout o~ block area 103, where the segment boundaries are shown with dashed lines and the block boundaries are shown with solid lines.
Block area 103 comprises handle block 210, master block 211, data blocks 212 and end block 213. A requesting program AC~CS~-c a data block using a block identifier, which may be a handle or a pointer. A handle is an identif ier o~ an allocated block oî memory and can be thought of as A pointer to a pointer. When a requesting program requests a block o~ memory, the Heap Manager allocates a block of memory and returns to the requesting program a block identifier ~or the allocated block.
Whenever the program requests a management service ( e . g ., ~reeing a block), the program identifies the block using the block identi~ier. Handle block 210 is preferably located below data blocks 212 so that handle block 210 will not be moved during heap compaction as ~ i c~--c5.,~
below .
Master block 211 is preferably located between handle block 210 and data blocks 212. Master block 212 contains available memory space that can be transf erred to the top of handle block 210 or to the bottom o~ data blocks 212. When the heap is init;A~ , the master block contains all available ~ree space. The Heap ~lanager allocates a data block to a requesting program by transferring free space from the top of master block in the ~orm oî a data block. Because it can be used to provide additional space rOr blocks above and below it, the master block may not always contain extra space. Data blocks 212 are those blocks that are either allocated to a requesting program or ~ree and available for allocation.
The allocation and freeing of blocks is described below and illustrated in Figures 4 and 5, respectively. E~nd ~ WO 94/02898 PCI`/US93/07021 ~, 21 19788 block 213 contains free space to be used during a heap shake, which is described in more detail below under the heading "Debugging. " Master block 211 2nd end block 213 are marXed as allocated blocks so that they will not be 5 allocated to a re~uesting program. End block 213 i5 also used during freeing a data block.
Figure 3 is a schematic diagram showing the relat;r~nch;r between the control area and a portion of the block area. In this example, the block area has been 10 divided into eight segments (segment boundaries 340-342 are shown with dashed lines). The control area contain~ a size tree 300 and a maximum free block array 310. Entries 320-327 in the maximum free block array ,ULLe ~u~ l to segments 0-7 in the block area, respectively. Only data 15 blocks in segments 5 and 6 are shown in Figure 3. Entry 326 in the maximum free block array 320 points to the beginning of the free list for segment 6. Block 331 is the beginning of that free list. Block 331 in turn contains a pointer to the next smaller free block 332, and 20 block 332 contains a pointer to the next smaller free block 333. Note that the free block 334 is not inc~
in the free list for segment 6, even though free block 334 extends across segment boundary 341. Entry 325 in the maximuIl free block array 310 contains a pointer to free 25 block 334, the beginning of the free list ~or segment 5.
The free list for segment 5 contains blocks 334-336.
The example used in Figure 3 shows entries 320-324, and 327 of the maximum free block array 310 (-_ULL'~ LJ~,..l;ng to segments 0-4 and segment 7, 30 respectively) containing null pointers. A null pointer indicates that no free blocks are available in the corr~cp~nrl;nq segment. Leaf nodes 304, 305 (Corr~cpon~;
to entries 320-323, which in turn correspond to segments 0-3 ) each contain a o value to ref lect the size of the 35 largest free block in segments O through 3. Leaf node 306 contains 30, which is the size of the largest free block in segments 4 and 5. Leaf node 307 contains 40, which is WO 94/02898 PCI/I~S93/07021 97 aa- 10 the size of the largest free block in segments 6 and 7.
Because each node of the size trQe contains the size of the large5t free block available in its subtree, node 302 contains 0 and node 303 contains 40. The root node 301 5 contains 40, which is the size of the largest free block in the heap.
In an alternate Dmhorl; L, the size tree for the above example would consist only of nodes 303, 306, and 307. Node 303 would be the root node. The Heap lO Manager maintains a pointer in header area 102 of Figure 1 to the root node of the size tree. Segments 0-3 would not be represented in the size tree because they do not contain any free blocks. This ~mho~l; L of the size tree would reduce the amount of searching that needs to be done 15 to find a free block of a particular size. If a block becomes free in segrlents 0, l, 2, or 3, then the size tree 300 would grow to include nodes 301, 302, 304, and 305 and the pointer to the root node would be adjusted accordingly .
20 The Heap Manager described herein ~ L:, both handle and pointer references to data blocks. During ~-~; on, the Heap Manager will perform an optional call back to the requesting program indicating that the Heap Manager is moving a block to a new location. The requesting program can then update any pointers it may be using to reflect the new location of the block. During allocation, ir no handles are available in the handle block, the Heap Manager takes space from the bottom of the master block to enlarge the handle block. If the master block is too small, the Heap ~anager compacts the heap and retries the request. Alternatively, the Heap Manager calls a routine S~rrl i ~d by the requesting program. This routine is described below under the heading "Compacting the Heap . "
~llocatinc a Data Block. Figure 4 is a flow diagram of a preferred ~mho~;r-nt of the present invention. The flow diagram outlines a method used by the -~ WO 94/0Z898 . lr/US93/07021 Heap Manager to allocate a data block to a requesting program. An allocation request for a data block having a requested size is passed to the Heap ~anger. The process begins in step 401 where the Heap Manager derPrm;nP~ the size of the block needed. The Heap Manager must add the size of the size field and any other administrative fields used internally by the Heap Manager to the size requested by the requesting program. In step 402, the Heap Manager determines if the request can be satisfied by comparing the size of the block needed with the value contained in the root node of the size tree (which is the size of the largest free block). The Heap ~anager maintains a pointer to the root node of the size tree in header area 102 of Figure 1. If the size of the block needed is less than or equal to the value contained in the root node of the size tree, then a data block is currently available to satisfy the data block request.
The process ~ont;mlaC to step 406 where the Heap Manager searches the size tree in a right-hand manner for a block large enough to satisfy the request. The tree is searched in a right manner to ensure that free blocks at higher addresses will be allocated bef ore ~ree blocks at lower ad-lLæsses. For example, if both child nodes contain values that are large enough to satisfy the request, the right child node is selected over the left child node. In the same way, if both entries in the maximum free block array point to free lists that contain a block large enough to satisfy the request, the right entry is selected over the left entry.
Once the Heap Manager selects an entry in the maximum free block array, the process continues to step 407 where the Heap Manager searches the free list pointed to by the selected entry to f ind and select the smallest available free block which will satisfy the request.
After such a free block has been selected, in step 408 the Heap Manager deta~m;nPs whether the selected free block is large enough to partition into two blocks and still WO 94/02898 PCI/US93/07021~
2~ i 9~8~8 12 satisfy the request. A free block is large enough to partition into two blocks if one block is large enough to satisfy the request and the other block is large enough to store the nr~r-r~q~i-ry pointer information and block size.
If so, the process continues to step 409 where the block is partitioned into two blocks - one f or allocation to the requesting program and one to remain in the free list.
The L- ;ninrJ portion of the free block is inserted into the free list at the appropriate location and, if nr~r r~c5~ry~ the size tree and maximum free block array are updated with the new (smaller) maximum size.
I~ the s~ t~ free block is not large enough to partition into two data blocks and still satisfy the request, in step 410 the Heap Manager removes the selected rree block from the free list and, if nr~r~cci~ry, the size tree and maximum free block array are updated. The process ends with step 412 where the Heap Manager marks the selected free block as allocated by clearing the free hint field and the low-order bit of the size field. The Heap Manager returns to the requesting program a block identi~ier that is a handle or pointer reference to the address of the 5~.1r~r 1-r rl free block. The block identifier references a memory location immediately above the size f ield .
Re~erring to step 402, i~ the size of the data block needed is larger than the value contained in the root node of the size tree, then a free block is not available in the block area to satisfy the request. The Heap Manager attempts to satisfy the requesting program by taking space from the master block if space is available The size of the master block is stored in the size field of the master block and the pointer to the master block is stored in the header area. Before taking space from the master block, in step 403 the Heap Manager tries to extend the master block by consolidating it with a ~ree block that might be located immediately above the master block.
Then, in step 404, the Heap Manager determines i~ the data W<~ 94/02898 PCI`1US93~D7021 13 : 2ll9788 block request can be ~ ted by the master block.
Thls determination is made by comparing the size of the data block needed with the size of the master block. If the master block is not large enough to satisfy the 5 request, the Heap Manager ~akes an out of memory call in block 405 and the returns to block 402 to retry.
Alternatively, the Heap Manager calls a routine supplied by the requesting program. This routine is described below under the heading "Compacting the Heap. "
10 After compaction, the process loops back to step 402 where the Heap Manager determines if there is enough memory to satisfy the request. If, after compaction or expansion o~
the heap, there is not enough memory to satisfy the request, the Heap Manager noti~ies the requesting program 15 that the request cannot be satis~ied.
If, in step 404, the master block is large enough to satisfy the request, the process skips to step 411 where the Heap Nanager transfers the requested amount of space from the master block to create a new data block.
20 Arter the data bloc3c is created rrom space transferred ~rom the master block, the procass ends with step 412 wherQ the Heap Nanager marks the newly created data block as allocated by clearing the low-order bit of the size f ield . The Heap Manager returns to the requesting program 25 a block identifier for the newly created block. The block identifier refers to the memory immediately above the size field of the block.
PrPPina a Data Block. Figures 5A-B illustrate a f low diagram of a pref erred A_~Orl; - t of the present 30 invention. The flow diagram outlines a method used by the Heap Manager to deallocatQ or free a data block. When a data block is freed, it is, ' ;n~-l with any free blocks that are located immediately above or below it in the heap . A requesting program passes the block identif ier of 35 the data block that is to be ~reed (the current block) to the Heap Manager.
W0 94/02898 PCI/US93/07021~
, .~.
2l ~ 9788 14 The process begins in step 502, where the Heap Nanager sets a pointer to point to the beginning of the current block by adjusting the block identif ier provided by the requesting program. The size f ield contains the 5 size of the block, and is located at the beginning of the block. The process continues on to step 503 where the Heap Nanager checks the free hint field of the block immediately below the current block . The free hint f ield is the last f ield in each data block . The free hint f ield 10 allows the Heap Manager to quickly check to see whether a block ~ight be free.
If the free hint f ield of the block irlmediately below the current block contains a signature value, the block might be free. When the free hint field does not 15 contain a signature value, then the block is allocated.
If the free hint field indicates the block is allocated, the process skips to block 510 in Figure 5B. If the free hint field indicates the block might be free, the Heap Manager ~ust do further -h~ ; n5 to determine whether the 20 block is free. The free hint field does not guarantee the block is free; data contained in an allocated block might look like the signature value used by the Heap Nanager.
When the free hint field of the block immediately below the current block (the lower block) 25 indicates the block ~ight be free, the Heap Manager ~ust check the low-order bit of the size rield in the lower block . To f ind the starting location of the lower block, the Heap Manager searches the free list for the segment that contains the current block (the current segment) to 30 try to find the lower block. As the Heap Manager traverses the free list, it checks the address of each block in the free list until it finds an address below the address of the current block. By adding the size af the f ound block to the address of the block, the Heap Manager 35 can determine if the block is immediately below the current block.
~ ~ WO 94/02898 PCI/US93/07021 15 2-t 1 978~
If the lower block is not in the free list for the current segment, the Heap Manager must search the segments below the current segment. The Heap Manager searches the entries of the maximum ~ree block array C.l~lLL~ .l;n~ to segments below the current segment until a non-null pointer entry is found. once a non-null pointer entry is found, the Heap Manager searches the free list pointed to by the entry to determine if the free list contains a rree block that is ~ust before the current block.
In steps 504-505, the Heap Manager PY~minPC the free list for the segment that contains the current block (the current segment) to determine whether a free data block exists immediately below the current block. I~ a free block is not found in the free list for the current segment, the process continues on to step 506, else the process skips to step 509 in Figure 5B. In steps 506-507, the Heap Manager searches the maximum free block array backwards, starting below the entry ~ L__ ,onding to the current segment entry, to find the next non-null pointer entry . If no such entry is f ound, the process skips to step 510 in Figure 5B.
If a non-null pointer entry is f ound, the process continues on to step 508 where the Heap Manager ~-Y~mi nPC the free list pointed to by the non-null pointer entry in the maximum free block array to determine if a free block exists immediately below the current block. If no such free block is found, the process skips to step 510 in Figure 5B. If such a free block is found, the process continues on to step 509 in Figure 5B.
Referring to Figure 5B, in step 509, the Heap Manager consolidates the current free block with the free block immediately below it and removes the lower free block from the free list for the lower block.
Next, in steps 510-511, the Heap Manager ~Y~m; nPC the data block above the current block (the upper block) to determine if that block is free. Because the _ _ _ . _ _ . ,,,, , _ . . , , _ _, . _ _ _ _ . _ W0 94/02898 PCI/US93/07021~
2t 1 9788 16 size of the current block i5 stored in the size field, the Heap Manager determines the address of the block immediately above the current block by adding the size of the current block to the address of the current block.
5 once the address is known, the Heap Manager can also determine which segment contains the upper block. The low-order bit of the size field is set if the block is free, and clear if the block is allocated. If the upper block is free, the process continues on to step 512 where lO the Heap Manager removes the upper block from its free list and then updates the size tree, if nPr~ccAry, When the current block is located at the top of the block area, the end block is immediately above the current block. Because the end block is marked as 15 allocated, the Heap Manager does not combine the current block with the end block. The end block guarantees that a valid block will always exist above a block being freed.
In step 513, the Heap Manager rnneol i~late5 the upper block with the current block. I~ the upper block is 20 not free, the process skips to step 514. In step Sl4, the Heap Nanager marks the current block as free by setting the low-order bit of the size f ield to l and by writing a signature value to the free hint rield. The Heap Manager then adds the current block to the free list for the 25 current segment, and, if n~ cs~ry, updates the size tree and the maximum free block array.
ComDactinq the HeaD. When the Heap Manager cannot locate a free data block in the heap large enough to satisfy an allocation request from a requesting 30 program, the Heap Manager compacts the heap and retries the request. Alternatively, the Heap Manager calls a routine supplied by the requesting program. The routine may do whatever actions are appropriate i n~ ng making other service requests to the Heap Manager to free memory.
35 Normally, the routine supplied by the requesting program will either return with no action (which will cause the allocation request to return with a null value) or it will WO 94~02898 PCrJUS93/070Z1 _ 2~ 19788 execute some combination of service requests to free data blocks or request the Heap Manager to compact the heap.
During compaction, the Heap Manager, for each data block to be moved, calls a routine, if one is supplied by the 5 requesting program, to notify the requesting program what the new address of the data block will be. The requesting program can then change any pointers it has to the data block .
Figures 6A-6B are detailed ~low diagrams of a 10 preferred c-~hq~;~ L of the present invention. The flow diagram outlines a method used by the Heap Manager to compact the heap by moving all allocated blocks to higher memory addresses, thereby creating one large free block of ~nemory at the bottom of the data block area. The new free 15 block i5 then incorporated into the master blocX.
Alternatively, a requesting program can allocate a larger or smaller size for the heap.
Referring to step 601 in Figure 6A, the Heap Manager scans all of the data blocks in the heap and links 20 all the free blocks together. The size field, located at the beginning of each block, contains the size of the block and is used to locate the next block. The Heap Nanager links the free blocks from the top of the data block area (higher address) to the bottom of the data 25 block area ~lower address). After Sr~nninq all of the data blocks and linking the free blocks together, in step 602 the Heap Manager der~i n~C whether the requesting program has allocated a new size for the heap. The requesting program has the option of allocating a larger 30 or a smaller size for the heap. When the requesting program requests a smaller size for the heap, the resulting heap size will be the larger of the requested size or the size required to contain the allocated blocks.
When the requesting program allocates the heap 35 to a new size, the control area is moved to the top of the new size heap. I~ the heap has been allocated to a new size, the process continues on to s~ep 603, where the Heap WO 94~02898 2 ~ 1 9 7 8 8 PCI/US93/0702 ~
Manager calculates the number of segments for the new size heap and then in step 604 determines the new location of the maximum free block array and the size tree.
When a heap is allocated to a new smaller size, 5 the compaction is initially executed as though the heap was not changing size. Then, after this first stage the entire group of compacted allocated blocks is moved down to its final position. The difference between the source and destination of this f inal move is ref erred to as the 10 shift down amount. When a heap is made larger or kept the same size, the shift down amount is zero. If the heap has not been alloczted to a new size, the process skips from step 602 to step 60~.
In step 605, the Heap Manager scans the linked 15 list of free blocks and stores a value in each block representing the total amount of free space scanned so far. The total amount of free space is stored in a free space field located within each free block. Preferably, the same space is used for the free hint fleld and the 20 rree space field. This value represents the amount each allocated block below each particular free block will be moved during compaction.
In steps 606-610, the Heap Manager determines the amount each allocated block of memory will be moved 25 during compaction and updates the handles to these blocks accordingly. A handle can be free or allocated; an allocated handle contains an indirect re~erence to an allocated block. Handles are stored in handle block 210 referenced in Figure 2B. In step 606, the Heap ~anager 3 0 scans the handle block and selects the next allocated handle, beginning with the first one.
In step 607, the ~eap Manager determines whether all of the handles have been selected. If all of the handles have not been selected, the process continues on 35 to step 608. In step 608, the Heap Manager selects the allocated block ref erenced by the selected handle . In step 609, the Heap Manager attempts to locate the f irst _ ~ WO 94/02898 'CI/US93/07021 2~ ~97~8 lg free block above the selected block. If there is no free block above the selected block, the process loops back to step 606 where the Heap Manager selects the next allocated handle. The Heap Manager locates the free block by f irst 5 def~mi n; nq which seqment contains the 5a~ e~ block.
The Heap Manager then searches the maximum free block array f or a non-null pointer entry ~_~ r L ~ n~ i nq to a segment above or ; n~ 3 i ng the segment that contains the s~1 ected block.
Once a non-null pointer entry is found, the Heap Manager searches the free list that is pointed to by the non-null pointer to locate the lowest address free block above the block ref erenced by the handle . Note that the free list at this time is the list of free blocks created 15 previously in step 601. Once the free block is located, in step 610, the Heap Manager updates the address stored in the s~l e-tPd handle by adding to it the value in the free space field of the free block minus any shift down factor. The Heap Manager repeats step 606 through 610 20 until all of the handles to the allocated blocks have been selected and updated.
Referring to Figure 68, in steps 611-613, the Heap Manaqer moves the allocated blocks to higher addresses, causing all of the free blocks to Ar~ Ate at 25 the bottom of the data block area. In step 611, the Heap Manager selects the next free block, starting with the ~irst one in the linked list generated in step 601. Each ~ree block contains a value in the free space field that indicates the amount of ~ree space above and including the 30 free block. In step 612, the Heap ~anager determines whether all of the free blocks have been scanned. If all of the free blocks have not been scanned, in step 613, the Heap Manager moves each allocated block in between the S~l aci ~ free block and the free block below it to new 35 higher adl.asses. A new address is calculated by adding the old address to the value stored in the free space field of the selected free block.
_ _ _ . _ _ . .. . _ . _ _ _ _ _ , WO 94/0289~ PCr/US93/07021 ~l ~ 9788 20 .
The Heap Nanager repeats steps 611-613 until all of the free blocks have been scanned and the allocated blocks have been moved upward the appropriate amount.
A~ter all of the free blocks have been scanned, in step 5 614, the Xeap Manager moves all the allocated blocks down to their final position as indicated by the shift down factor if any. Any resulting free space that has been ar~ Ated at the bottom of the data block area is added to the master block in step 615. In step 616, the size 10 tree and maximum free block array are reinitialized to re~lect that there are no longer any free blocks in the heap .
Figures 7A and 7B are schQatic diagrams used to illustrate an example of the compaction process. Figure 15 7A is a schQatic diagram of size tree 700, maximum free block array 710, data block area 730, and handle block 750 bef ore compaction, while Figure 7B is a schematic diagram of size tree 700, maximum free block array 710, data block area 730, master block 740, and handle block 750 after 20 compaction. Even though the handle biock is preferably located at the bottom of segment 0, for purposes of this ~xample, handle block 750 is shown without reference to a segment number. The dashed lines in data block area 730 represent segment boundaries, while the solid lines 25 ~LL ~.lL block boundaries. Data block area 730 is divided into 8 segments.
In this example, a reguesting program has ~ade an allocation request for a block of memory having size 10. Referring to Figure 7A, the allocation request has 30 ~ailed because the size of largest free block available is 6, as indicated by the root node 701 of the size tree 700.
Additionally, the master block was too small for the Heap ~Sana~er to transfer free space. Data block area 730 ~nrl~rlPc free blocks F0-F3 and allocated blocks A0-A8.
35 Handle block 750 i nrl~ Pc handles H0-H8, which identify the location of allocated blocks A0-A8, respectively. The size o~ each block is stored in a size field, which is the -~ WO 94102898 PCI/US93/07021 21 2 1 ~ 9 78~3 first field of each block. For example, the size of block A0 is 6.
The goal of c3~paction is to consolidate all of the free blocks in data block area 730 to add to the master block. To do this, allocated blocks A0-A7 will have to be physically moved to higher addresses.
Allocated block A8 will not be moved because there are no ~ree bloclcs located a~ove it. To determine the amount each allocated block must be moved, the Heap Nanaqer f irst scans all of the data blocks and creates a linked list of free blocks by linking together free blocks F0-F3 from the top of the data block area to the bottom. Each free block contains a pointer to the next lower free block. The pointer is pre~erably located a~ter the size f ield. The Heap Manager then scans the linked list of free blocks, storing a value in each block representing the cumulative amount of free space scanned so far. This value is stored in the free space f ield.
For example, the Heap Nanager stores 4 in the free space field Or rree block F3 because ~ree block F3 has size 4, and 4 is the amount of free space scannQd so far. The Heap Manager then stores 10 in the free space field of free block F2, which Le:~L~Sc:llLS the size of free block F3 plus the size of free block F2. The Heap Manager 2S stores 12 and 16 in the free space fields of free blocks F1 and F0, respectively. The value stored in the free space field of the last free block in the linked list of free blocks represents thQ total amount of free space in the data block area.
After de~Prm;n;~ the amount of ~ree space above and ;nr~ ;ng each free block and before moving each allocated block, the Heap Manager updates handles H0-H8.
As described above, a handle is an identif ier of an allocated block of memory. ~o update a handle to an allocated block, the ~eap Manager computes how much the address of the allocated block will change when the allocated block is moved. The value stored in the free WO 94/02898 PCr/US93/07021~
space field of a free block is the amount that each allocated block in between the free block and a next lower free blocX will have to be moved. For example, allocated blocks A3-A5 will be moved up 10, the value stored in the 5 free space field of free block F2 minus the shift down amount, which in this case is 0.
The Xeap Manager selects the f irst handle H5, which is a handle to allocated block A5. Based on the address of block A5, the Heap Manager derarminas which 10 segment contains block A5. Segment 3 contains bloc3c A5, because block A5 starts at address 3 0 . Next, the Heap Manager looks at entry 723 in maximum free block array 710 (entry 723 ~ u~ ul-ds to segment 3) to determine if there are any free blocks in segment 3. Entry 723 contains a 15 null pointer, indicating there are no free blocks in segment 3.
The Heap Nanager then searches maximum free block array 710 starting with the entry for segment 4, searching f or the f irst non-null pointer entry . Entry 20 724, c, - -" , l;n~ to segment 4 contains a non-null pointer entry. The Xeap Manger searches the linked list of free blocks, starting with the free block pointed to by entry 724, searching for the free block whose address is closest to and greater than the address of allocated block 25 A5. Entry 724 points to free block F2. Free block F2 is located above allocated block A5. The Heap Manager updates handle X5 by adding the value stored in the free space field of free block F2 (10) to the address of allocated block A5 (30), and then subtracting any shift 30 down amount. The result is 40, which will be the address of allocated block A5 after it is moved. The new address is stored in handle X5, as shown in Figure 7B. The above process is repeated to update the rr-~ i n i n~ handles .
After all of the handles have been updated, the 35 Heap Manager physically moves each allocated block. The Xeap Manager selects the first free block F3 in the linked list of free blocks, and determines which allocated blocks ~ WO 94/02898 PCr~US93/07021 23 21 1~788 are between free block F3 and the next free block in the linked list, free block F2. The Heap ~anager then moves all of the allocated blocks in between free blocks F3 and F2 up by the amount stored in the free space f ield of free 5 block F3. Therefore, allocated blocks A7 and A6 are moved up 4 units. The Heap Nanager then selects the next ~ree block F2. Because free block F2 contains the value lO in its free space field, all of the allocated blocks between free blocks P2 and Fl (allocated blocks A5-A3) are moved lO up lO units. This process continues until all of the allocated blocks have been moved up the appropriate amount. Note that allocated block A8 is not moved because there is no free space above it. If the heap is being made smaller, data blocks A0-A8 are moved down by the 15 shi~t down amount.
Figure 7B shows the results of the compaction.
Data block area 730 contains allocated blocks A0-A8 with no free space in between the allocated blocks. Free blocks F0-F3 of Figure 7A have been consolidated into 20 master block 740 of Figure 78. Handle block 750 contains handles H0-H8. Size tree 700 and maximum free block array 710 have been reini~ od because data block area 730 does not contain any free blocks.
Debuqqinq. The present invention also provides 25 a method for locating pointers that have not been correctly updated by a requesting program. Requesting ~IL~I~LC~1..3 ~ use pointers to identify allocated blocks. To ensure that these pointers are properly updated when an allocated block is moved, the present 30 invention provides a debugging mode in which allocated blocks are automatically moved . In ef f ect, the heap is "shaken" to force any pointer errors to surface. Nhen heap shake is enabled, the Heap ~Sanager moves all data blocks a prede~-min~ amount after satisfying an 35 allocation request. Nhen each allocated block is moved, a routine (optionally supplied by the requesting program) is inYoked to update any pointers the requesting program has to the moved block.
After all blocks are moved the maximum amount, the blocks are moved back to their starting positions.
S IIJV~ L space for this "heap shake" is preferably maintained in the end block, located above the data block area. The end block is never allocated to a requesting program and the master block is never reduced beyond what is currently necessary to support a heap shake. 3uring each "shake" all of the internal free block pointers are updated by scanning free blocks and adding or subtracting the predetPrmi n~d shake amount. Then each data block (allocated and free) is moved to its new position.
Lastly, all the handles to the allocated blocks are updated to their new values by adding or subtracting a constant. To prevent having to update the size tree, the maximum free block array, and the free lists for each segment, segment addresses are calculated from an adjustable base which is updated after each heap shake.
Although the methods and systems of the present invention have been described in terms of a preferred ~-mho~ , it is not intended that the invention be limited to this ~mho~ r t . Modif ications within the spirit of the invention will be apparent to those skilled in the art. The scope of the present invention is def ined only by the claims that foll~w.
ALLOCATING AND FREEI~G ~EMORY
TPrhn i CA ~ Field This invention relates generally to a computer method and system for memory -~n5-, L, and, more 10 particularly, to a method and system for allocating, ~reeing, and compacting memory that uses a heap structure.
Bach~lL u~ of the Tnvention A computer system may manage computer memory 15 dynamically. Dynamic memory management refers to the process by which blocks of memory are allocated temporarily rOr a SpPri f i r purpose and then ~ rated or freed when no longer needed ~or that purpose. Free blocks are available ~or reallocation for another purpose. The 20 process that dyn~ir~l ly manages memory is referred to as the memory manager. The memory that the memory manager manages is referred to as a "heap. " A heap is a portion of memory 1-3S~LV-:d for a program to use for the temporary storage of data structures whose existence or size cannot 25 be de~Prm; nPd until the ~~~gram is running . The program can request a block of free memory having a certain size, use it, and later request that the block be freed. The memory manager allocates dif~erently sized blocks of memory from the heap according to the needs of the 3 0 requesting program .
When a program needs a blocX of memory, the program sends a re~uest to the memory manager. The memory manager allocates a block of memory from the heap to satisfy the request and then sends a handle or pointer to 3 5 the block o~ memory back to the res~uesting program . The re~uesting program can then access the block of memory through the handle or pointer. When the requ sting _ _ _ _ _ _ _ _ _ _ _ _ . ... ...
WO 94/02898 PClr/US~3/07021~
z~ l9788 2 program is rinished using the block o~ memory, the program notif ies the memory manager that the block is no lonqer needed. The memory manager then frees the block of memory to make the block available rOr allocation. When the 5 memory manager cannot allocate a block of memory to a requesting program (because the heap does not contain a large enough block), the memory manager usually compacts the heap to consolidate all of the free blocks.
lO S rv of the Invention It is an object of the present invention to provide an ; ~ve:d memory management process for a computer memory.
It is another obj ect of the present invention to 15 provide an i .,v~:d method of allocating a block of memory to a requesting program.
It is another object of the present invention to provide an improved method of freeing a block of memory when the memory is no longer needed by a requesting 2 0 program .
It is yet another obj ect of the present invention to provide an i ~Jved method of compacting memory .
These and other objects, which will become 25 apparent as the invention is more fully described below, are obtained by an improved method and system for dynamic memory management. In a pre~erred PT~hOA i~ L, a requesting program running on a computer system allocates ~ contiguous block of memory (a "heap") for the temporary 3 0 storage o~ data structures . A Heap Nanager, provided by the present invention, manages the heap in response to instructions from the requesting program. The Heap Nanager divides the heap into 2n segments having unif orm size. The Heap Nanaqer allocates blocks of memory to the 35 requesting program. When the requesting program is ~ ;n; -:h.Q~ using a block of memory, the E~eap Manager frees . .
. . ~
WO 94/02898 PCl`/US93~07D21 ~ ~97~8 the block of memory so that the block of memory can be allocated .
In a preferred ~mho~;- L, the Heap Manager maintains a free list for each segment, which is a linked list of the free blocks beginning in that seg_ent. Each ~ree list is ~rr~cs;hle through a maximum free block array and a size tree. The maximum free block array has a plurality o~ entries; each entry .ULL_a~UUI~dS to a segment and points to the boq; nn; ng of the free list ~or the segment. The size tree is a complete binary tree, arranged in such a way that the value of each node is equal to the largest value of its child nodes. Each leaf node of the size tree ~ urLo,~ùl~-ls to two entries in the maximum free block array. The value contained in each leaf node indicates the size of the largest ~ree block in the s~ L~ CC)LL_ ~u~ ;nrJ to two entries in the free block array.
The Heap Manager allocates a block of memory to a requesting program by selecting a free block of memory o~ a requested size from the heap. The Heap Manager selects the free block by searching the size tree and free block array and selecting a segment that c~-nt:-; nC a free block that will satisfy the request, and then searching the free list CuLL~ ;ng to the selected segment to locate the smallest free block that satisfies the request.
The Heap Nanager frees a block of memory at the request of a requesting program and consolidates the ~reed block with any free blocks that may be located immediately above or below the freed block.
When the Heap Manager cannot satisfy an allocation request, the Heap Manager makes an out of memory call, which gives the requesting program the option of compacting the heap, or allocating the heap to a larger or smaller size. The Heap Manager ~ -~tc the heap by moving the allocated blocks to higher addresses in the heap, thereby consolidating the free blocks at the lower addresses. The Heap Manager optionally maintains handles WO 94~02898 PCr/US93/07021 to the allocatad blocks to keep track of where they are moved. ~ihen the requesting program provides a call back routine, the Heap Nanager invokes the call back return to notify the requesting progra~ when an allocated block is S going to be moved so that the requesting program can update any pointers Lt has to the allocated block.
Brief Descri~tion of t~h~e Drawinqs Figure 1 is a schematic diagram showing the 10 relarinnch;~ between a requesting program, the Eleap Manager, and the heap.
Figure 2A is a sample segment layout of the block 2rea referred to in Figure 1.
Figure 2B is a sample block layout of the block 15 area referred to in Figure 2A.
Figure 3 is a schematic diagram showing the relation~h;r between the control area and a portion of the block area.
Figure 4 is a detailed ~low diagram of a method 20 used by the present invention to allocate a data block to a requesting program.
Figures 5A-B are detailed ~low diagrams of a method used by the present invention to free a data block at the request of a requesting program.
Figures 6A-B are detailed flow diagrams of a method used by the present invention to compact the heap.
Figure 7A is a sc_ematic diagram of the size tree, maximum free block array, data block area and handle block bef ore compaction .
Figure 7B is a schematic diagram of the size tree, maximum free block array, data block area, master block, and handle block after _ ~-t-; nn, Detailed Descrir~tion o~ ~he Invention The present invention provides a method and system ~or dyn2mic memory management of a heap. A heap is a logically contiguous area of memory used by a requesting , ~
~ WO 94~02898 PCI~/US93/07021 program for the temporary storage of data ~LLU~.~U~=S. A
program called the Heap ~anager responds to service requests made by a requesting program running on a computer system. The service requests include allocating, 5 freeing, and compacting memory space within the heap.
Figure 1 is a schematic diagram showing the relarionch;~
between the requesting program 100, the Heap ~an~ger lol, and the heap 10 5 .
In a preferred ,~mho~i -nt, a memory manager 10 maintains various data structures within the heap.
Referring to Figure 1, in a preferred ~ o~i ~ of the present invention, a heap 105 is divided into three major areas: header area 102 which holds control inf ormation;
block area 103 which contains blocXs of memory that are 15 allocated ana freed upon request; and control area 104 which contains control information. Header area 102 is physically located below block area 103, which is physically located below control area 104. When referring to locations within the heap, "below" means at a lower 20 memory address, while "above" means at a hiyher memory address. Alternatively, header area 102 and control area 104 are not physically located next to block area 103.
Header area 102 contains control information, such as the size of the heap and pointers to ~Luu~uLes in 25 control area 104 and to speci~ic blocks within block area 103. Block area 103 is divided into segments. A segment is a logically contiguous area of memory used by the Heap Manager in maintaining lists of free blocks. The division of }~lock area 103 into segments is described in more 30 detail below. Block area 103 is also divided into blocks.
A block i5 a logically contiguous area of memory which is allocated and freed by the Heap Manager at the request of a re~uesting program.
Each block in block area 103 begins with a size 35 field which indicates the size of the block. Block sizes are preferably even numbers because the low-order bit of the size field is used to indicate whether the block is .. , _ . _, _ . , . ., ,,,,, . . , .... , _ _ , _ _ _ _ _ . _ _, .
WO 94/02898 PCltUS93/07021~
` 2i ~ 97~ ` 6 free. A free block has the low-order bit of the size field set while an allocated block has this hit clear.
All free blocks within a segment are linked together to rorm a rree list ~or that segment. Each free block contains a pointer, pre~erably located after the size f ield, to the next smaller ~ree block that starts in the same segment. Thus, each segment has a ~.u, r-~v-.ding free list which is a linked list (accordinq to size) of free blocks in that segment . The last f ield of each block is used as a free hint field. The free hint field is set to a unique signature value ir the block is free. The free hint f ield is used when freeing a block to aid in de D~m;n;ng whether the freed block is adjacent to a free block. If so, the rreed block is combined with the I5 adjacent free block to form one rree block.
Control area 104 comprises a maximum frQe block array and a size tree. The maximum free block array is a list that contains one entry for each segment. Each entry in the maYimUm ~ree block array points to the beginning of the free list for the segment that cu~ yvllds to the entry. As described above, the free list for each segment is a linked list of free blocks in the segment according to size, such that the largest free block in the segment is the beginning of the free list.
The size tree is a data structure that comprises nodes that are linked together in a hierarchical f ashion .
The nodes contain values ~ s~.i.ing the size of the largest free block in each subtree. The topmost node is called the root node. The root node has two child nodes and the root node is the parent node to its child nodes.
Each child node in the size tree has two child nodes of its own. Every node in the size tree has exactly one parent node, except for the root node, which has none. A
node that has no child nodes is called a leaf node. The size tree is a complete binary tree with the ~J.U~eL ~y that the value contained in any node is equal to the larger of the values contained in either of its child nodes. The . . ~
~ WO 94/02898 PCr/US93tO7021 7 2 ~ 1 97g8 size tree is preferably oryanized so that each child node is positioned at locations 2N and 2N+l for a parent node N. The size tree organizes the segments based on the size cf the largest free block in each segment. The size tree 5 contains N-1 nodes where N is e~ual to the number of s_, ~~ L:, in the block area . Each node of the size tree contains the size of the largest free block available in its subtree, so that the root node contains the size of the largest free block in the heap. Each leaf node of the 10 size tree ,UL' ~ Ul-dS to two entries in the maximum free block array such that the leaf node contains the size of the largest free block pointed to by the CULL~-1J~ ng entries in the maximum free block array.
The block area is divided into 2n sl, ~:, to 15 uuLL~u~ld with the size tree being a complete binary tree . In a pref erred embodiment, during heap initialization the Heap Manager determines the number of 8 ~, Ls by dividing the size of block area 103 by a minimum segment size and then rounding the result to the 20 next lower power of two. The minimum segment size (as specified by the re~uesting program) is an arbitrary value, commonly 1000 - 2000 bytes, based on the needs of the requesting program. The final segment size is de~Prm; nPd by dividing the size of block area 103 by the 25 number of s- L~;.
For example, i~ block area 103 contains 900 bytes and the minimum segment size is 100 bytes, then the ~eap Manager detPrminPc the final segment size as follows.
First, the Heap Manager divides the size of block area 103 30 by the minimum segment size, which results in 9 (900/100).
Second, the Heap Manager rounds the result to the next lower power of two to ~a~P~; nP the number of segments.
Nine rounded down to the next lower power of two results in 8 segments. Last, the Heap Manager divides the size of 35 block area 103 (900) by the number of segments (8) to determine the final segment size, which is 113 bytes (900/8). The last segment is only 109 bytes because the .. . ... . . . . .. . . . . _ .. .. _ . . ... _ _ WO 94/02898 _ PCr/US93/07021 21 ~ 97 88 8 number of segments Ln this example does not divide evenly Lnto the size of the block area. Figure 2A is a &le segment layout of block area 103 having ~ segments 200-207 .
Figure 2B is a sample block layout o~ block area 103, where the segment boundaries are shown with dashed lines and the block boundaries are shown with solid lines.
Block area 103 comprises handle block 210, master block 211, data blocks 212 and end block 213. A requesting program AC~CS~-c a data block using a block identifier, which may be a handle or a pointer. A handle is an identif ier o~ an allocated block oî memory and can be thought of as A pointer to a pointer. When a requesting program requests a block o~ memory, the Heap Manager allocates a block of memory and returns to the requesting program a block identifier ~or the allocated block.
Whenever the program requests a management service ( e . g ., ~reeing a block), the program identifies the block using the block identi~ier. Handle block 210 is preferably located below data blocks 212 so that handle block 210 will not be moved during heap compaction as ~ i c~--c5.,~
below .
Master block 211 is preferably located between handle block 210 and data blocks 212. Master block 212 contains available memory space that can be transf erred to the top of handle block 210 or to the bottom o~ data blocks 212. When the heap is init;A~ , the master block contains all available ~ree space. The Heap ~lanager allocates a data block to a requesting program by transferring free space from the top of master block in the ~orm oî a data block. Because it can be used to provide additional space rOr blocks above and below it, the master block may not always contain extra space. Data blocks 212 are those blocks that are either allocated to a requesting program or ~ree and available for allocation.
The allocation and freeing of blocks is described below and illustrated in Figures 4 and 5, respectively. E~nd ~ WO 94/02898 PCI`/US93/07021 ~, 21 19788 block 213 contains free space to be used during a heap shake, which is described in more detail below under the heading "Debugging. " Master block 211 2nd end block 213 are marXed as allocated blocks so that they will not be 5 allocated to a re~uesting program. End block 213 i5 also used during freeing a data block.
Figure 3 is a schematic diagram showing the relat;r~nch;r between the control area and a portion of the block area. In this example, the block area has been 10 divided into eight segments (segment boundaries 340-342 are shown with dashed lines). The control area contain~ a size tree 300 and a maximum free block array 310. Entries 320-327 in the maximum free block array ,ULLe ~u~ l to segments 0-7 in the block area, respectively. Only data 15 blocks in segments 5 and 6 are shown in Figure 3. Entry 326 in the maximum free block array 320 points to the beginning of the free list for segment 6. Block 331 is the beginning of that free list. Block 331 in turn contains a pointer to the next smaller free block 332, and 20 block 332 contains a pointer to the next smaller free block 333. Note that the free block 334 is not inc~
in the free list for segment 6, even though free block 334 extends across segment boundary 341. Entry 325 in the maximuIl free block array 310 contains a pointer to free 25 block 334, the beginning of the free list ~or segment 5.
The free list for segment 5 contains blocks 334-336.
The example used in Figure 3 shows entries 320-324, and 327 of the maximum free block array 310 (-_ULL'~ LJ~,..l;ng to segments 0-4 and segment 7, 30 respectively) containing null pointers. A null pointer indicates that no free blocks are available in the corr~cp~nrl;nq segment. Leaf nodes 304, 305 (Corr~cpon~;
to entries 320-323, which in turn correspond to segments 0-3 ) each contain a o value to ref lect the size of the 35 largest free block in segments O through 3. Leaf node 306 contains 30, which is the size of the largest free block in segments 4 and 5. Leaf node 307 contains 40, which is WO 94/02898 PCI/I~S93/07021 97 aa- 10 the size of the largest free block in segments 6 and 7.
Because each node of the size trQe contains the size of the large5t free block available in its subtree, node 302 contains 0 and node 303 contains 40. The root node 301 5 contains 40, which is the size of the largest free block in the heap.
In an alternate Dmhorl; L, the size tree for the above example would consist only of nodes 303, 306, and 307. Node 303 would be the root node. The Heap lO Manager maintains a pointer in header area 102 of Figure 1 to the root node of the size tree. Segments 0-3 would not be represented in the size tree because they do not contain any free blocks. This ~mho~l; L of the size tree would reduce the amount of searching that needs to be done 15 to find a free block of a particular size. If a block becomes free in segrlents 0, l, 2, or 3, then the size tree 300 would grow to include nodes 301, 302, 304, and 305 and the pointer to the root node would be adjusted accordingly .
20 The Heap Manager described herein ~ L:, both handle and pointer references to data blocks. During ~-~; on, the Heap Manager will perform an optional call back to the requesting program indicating that the Heap Manager is moving a block to a new location. The requesting program can then update any pointers it may be using to reflect the new location of the block. During allocation, ir no handles are available in the handle block, the Heap Manager takes space from the bottom of the master block to enlarge the handle block. If the master block is too small, the Heap ~anager compacts the heap and retries the request. Alternatively, the Heap Manager calls a routine S~rrl i ~d by the requesting program. This routine is described below under the heading "Compacting the Heap . "
~llocatinc a Data Block. Figure 4 is a flow diagram of a preferred ~mho~;r-nt of the present invention. The flow diagram outlines a method used by the -~ WO 94/0Z898 . lr/US93/07021 Heap Manager to allocate a data block to a requesting program. An allocation request for a data block having a requested size is passed to the Heap ~anger. The process begins in step 401 where the Heap Manager derPrm;nP~ the size of the block needed. The Heap Manager must add the size of the size field and any other administrative fields used internally by the Heap Manager to the size requested by the requesting program. In step 402, the Heap Manager determines if the request can be satisfied by comparing the size of the block needed with the value contained in the root node of the size tree (which is the size of the largest free block). The Heap ~anager maintains a pointer to the root node of the size tree in header area 102 of Figure 1. If the size of the block needed is less than or equal to the value contained in the root node of the size tree, then a data block is currently available to satisfy the data block request.
The process ~ont;mlaC to step 406 where the Heap Manager searches the size tree in a right-hand manner for a block large enough to satisfy the request. The tree is searched in a right manner to ensure that free blocks at higher addresses will be allocated bef ore ~ree blocks at lower ad-lLæsses. For example, if both child nodes contain values that are large enough to satisfy the request, the right child node is selected over the left child node. In the same way, if both entries in the maximum free block array point to free lists that contain a block large enough to satisfy the request, the right entry is selected over the left entry.
Once the Heap Manager selects an entry in the maximum free block array, the process continues to step 407 where the Heap Manager searches the free list pointed to by the selected entry to f ind and select the smallest available free block which will satisfy the request.
After such a free block has been selected, in step 408 the Heap Manager deta~m;nPs whether the selected free block is large enough to partition into two blocks and still WO 94/02898 PCI/US93/07021~
2~ i 9~8~8 12 satisfy the request. A free block is large enough to partition into two blocks if one block is large enough to satisfy the request and the other block is large enough to store the nr~r-r~q~i-ry pointer information and block size.
If so, the process continues to step 409 where the block is partitioned into two blocks - one f or allocation to the requesting program and one to remain in the free list.
The L- ;ninrJ portion of the free block is inserted into the free list at the appropriate location and, if nr~r r~c5~ry~ the size tree and maximum free block array are updated with the new (smaller) maximum size.
I~ the s~ t~ free block is not large enough to partition into two data blocks and still satisfy the request, in step 410 the Heap Manager removes the selected rree block from the free list and, if nr~r~cci~ry, the size tree and maximum free block array are updated. The process ends with step 412 where the Heap Manager marks the selected free block as allocated by clearing the free hint field and the low-order bit of the size field. The Heap Manager returns to the requesting program a block identi~ier that is a handle or pointer reference to the address of the 5~.1r~r 1-r rl free block. The block identifier references a memory location immediately above the size f ield .
Re~erring to step 402, i~ the size of the data block needed is larger than the value contained in the root node of the size tree, then a free block is not available in the block area to satisfy the request. The Heap Manager attempts to satisfy the requesting program by taking space from the master block if space is available The size of the master block is stored in the size field of the master block and the pointer to the master block is stored in the header area. Before taking space from the master block, in step 403 the Heap Manager tries to extend the master block by consolidating it with a ~ree block that might be located immediately above the master block.
Then, in step 404, the Heap Manager determines i~ the data W<~ 94/02898 PCI`1US93~D7021 13 : 2ll9788 block request can be ~ ted by the master block.
Thls determination is made by comparing the size of the data block needed with the size of the master block. If the master block is not large enough to satisfy the 5 request, the Heap Manager ~akes an out of memory call in block 405 and the returns to block 402 to retry.
Alternatively, the Heap Manager calls a routine supplied by the requesting program. This routine is described below under the heading "Compacting the Heap. "
10 After compaction, the process loops back to step 402 where the Heap Manager determines if there is enough memory to satisfy the request. If, after compaction or expansion o~
the heap, there is not enough memory to satisfy the request, the Heap Manager noti~ies the requesting program 15 that the request cannot be satis~ied.
If, in step 404, the master block is large enough to satisfy the request, the process skips to step 411 where the Heap Nanager transfers the requested amount of space from the master block to create a new data block.
20 Arter the data bloc3c is created rrom space transferred ~rom the master block, the procass ends with step 412 wherQ the Heap Nanager marks the newly created data block as allocated by clearing the low-order bit of the size f ield . The Heap Manager returns to the requesting program 25 a block identifier for the newly created block. The block identifier refers to the memory immediately above the size field of the block.
PrPPina a Data Block. Figures 5A-B illustrate a f low diagram of a pref erred A_~Orl; - t of the present 30 invention. The flow diagram outlines a method used by the Heap Manager to deallocatQ or free a data block. When a data block is freed, it is, ' ;n~-l with any free blocks that are located immediately above or below it in the heap . A requesting program passes the block identif ier of 35 the data block that is to be ~reed (the current block) to the Heap Manager.
W0 94/02898 PCI/US93/07021~
, .~.
2l ~ 9788 14 The process begins in step 502, where the Heap Nanager sets a pointer to point to the beginning of the current block by adjusting the block identif ier provided by the requesting program. The size f ield contains the 5 size of the block, and is located at the beginning of the block. The process continues on to step 503 where the Heap Nanager checks the free hint field of the block immediately below the current block . The free hint f ield is the last f ield in each data block . The free hint f ield 10 allows the Heap Manager to quickly check to see whether a block ~ight be free.
If the free hint f ield of the block irlmediately below the current block contains a signature value, the block might be free. When the free hint field does not 15 contain a signature value, then the block is allocated.
If the free hint field indicates the block is allocated, the process skips to block 510 in Figure 5B. If the free hint field indicates the block might be free, the Heap Manager ~ust do further -h~ ; n5 to determine whether the 20 block is free. The free hint field does not guarantee the block is free; data contained in an allocated block might look like the signature value used by the Heap Nanager.
When the free hint field of the block immediately below the current block (the lower block) 25 indicates the block ~ight be free, the Heap Manager ~ust check the low-order bit of the size rield in the lower block . To f ind the starting location of the lower block, the Heap Manager searches the free list for the segment that contains the current block (the current segment) to 30 try to find the lower block. As the Heap Manager traverses the free list, it checks the address of each block in the free list until it finds an address below the address of the current block. By adding the size af the f ound block to the address of the block, the Heap Manager 35 can determine if the block is immediately below the current block.
~ ~ WO 94/02898 PCI/US93/07021 15 2-t 1 978~
If the lower block is not in the free list for the current segment, the Heap Manager must search the segments below the current segment. The Heap Manager searches the entries of the maximum ~ree block array C.l~lLL~ .l;n~ to segments below the current segment until a non-null pointer entry is found. once a non-null pointer entry is found, the Heap Manager searches the free list pointed to by the entry to determine if the free list contains a rree block that is ~ust before the current block.
In steps 504-505, the Heap Manager PY~minPC the free list for the segment that contains the current block (the current segment) to determine whether a free data block exists immediately below the current block. I~ a free block is not found in the free list for the current segment, the process continues on to step 506, else the process skips to step 509 in Figure 5B. In steps 506-507, the Heap Manager searches the maximum free block array backwards, starting below the entry ~ L__ ,onding to the current segment entry, to find the next non-null pointer entry . If no such entry is f ound, the process skips to step 510 in Figure 5B.
If a non-null pointer entry is f ound, the process continues on to step 508 where the Heap Manager ~-Y~mi nPC the free list pointed to by the non-null pointer entry in the maximum free block array to determine if a free block exists immediately below the current block. If no such free block is found, the process skips to step 510 in Figure 5B. If such a free block is found, the process continues on to step 509 in Figure 5B.
Referring to Figure 5B, in step 509, the Heap Manager consolidates the current free block with the free block immediately below it and removes the lower free block from the free list for the lower block.
Next, in steps 510-511, the Heap Manager ~Y~m; nPC the data block above the current block (the upper block) to determine if that block is free. Because the _ _ _ . _ _ . ,,,, , _ . . , , _ _, . _ _ _ _ . _ W0 94/02898 PCI/US93/07021~
2t 1 9788 16 size of the current block i5 stored in the size field, the Heap Manager determines the address of the block immediately above the current block by adding the size of the current block to the address of the current block.
5 once the address is known, the Heap Manager can also determine which segment contains the upper block. The low-order bit of the size field is set if the block is free, and clear if the block is allocated. If the upper block is free, the process continues on to step 512 where lO the Heap Manager removes the upper block from its free list and then updates the size tree, if nPr~ccAry, When the current block is located at the top of the block area, the end block is immediately above the current block. Because the end block is marked as 15 allocated, the Heap Manager does not combine the current block with the end block. The end block guarantees that a valid block will always exist above a block being freed.
In step 513, the Heap Manager rnneol i~late5 the upper block with the current block. I~ the upper block is 20 not free, the process skips to step 514. In step Sl4, the Heap Nanager marks the current block as free by setting the low-order bit of the size f ield to l and by writing a signature value to the free hint rield. The Heap Manager then adds the current block to the free list for the 25 current segment, and, if n~ cs~ry, updates the size tree and the maximum free block array.
ComDactinq the HeaD. When the Heap Manager cannot locate a free data block in the heap large enough to satisfy an allocation request from a requesting 30 program, the Heap Manager compacts the heap and retries the request. Alternatively, the Heap Manager calls a routine supplied by the requesting program. The routine may do whatever actions are appropriate i n~ ng making other service requests to the Heap Manager to free memory.
35 Normally, the routine supplied by the requesting program will either return with no action (which will cause the allocation request to return with a null value) or it will WO 94~02898 PCrJUS93/070Z1 _ 2~ 19788 execute some combination of service requests to free data blocks or request the Heap Manager to compact the heap.
During compaction, the Heap Manager, for each data block to be moved, calls a routine, if one is supplied by the 5 requesting program, to notify the requesting program what the new address of the data block will be. The requesting program can then change any pointers it has to the data block .
Figures 6A-6B are detailed ~low diagrams of a 10 preferred c-~hq~;~ L of the present invention. The flow diagram outlines a method used by the Heap Manager to compact the heap by moving all allocated blocks to higher memory addresses, thereby creating one large free block of ~nemory at the bottom of the data block area. The new free 15 block i5 then incorporated into the master blocX.
Alternatively, a requesting program can allocate a larger or smaller size for the heap.
Referring to step 601 in Figure 6A, the Heap Manager scans all of the data blocks in the heap and links 20 all the free blocks together. The size field, located at the beginning of each block, contains the size of the block and is used to locate the next block. The Heap Nanager links the free blocks from the top of the data block area (higher address) to the bottom of the data 25 block area ~lower address). After Sr~nninq all of the data blocks and linking the free blocks together, in step 602 the Heap Manager der~i n~C whether the requesting program has allocated a new size for the heap. The requesting program has the option of allocating a larger 30 or a smaller size for the heap. When the requesting program requests a smaller size for the heap, the resulting heap size will be the larger of the requested size or the size required to contain the allocated blocks.
When the requesting program allocates the heap 35 to a new size, the control area is moved to the top of the new size heap. I~ the heap has been allocated to a new size, the process continues on to s~ep 603, where the Heap WO 94~02898 2 ~ 1 9 7 8 8 PCI/US93/0702 ~
Manager calculates the number of segments for the new size heap and then in step 604 determines the new location of the maximum free block array and the size tree.
When a heap is allocated to a new smaller size, 5 the compaction is initially executed as though the heap was not changing size. Then, after this first stage the entire group of compacted allocated blocks is moved down to its final position. The difference between the source and destination of this f inal move is ref erred to as the 10 shift down amount. When a heap is made larger or kept the same size, the shift down amount is zero. If the heap has not been alloczted to a new size, the process skips from step 602 to step 60~.
In step 605, the Heap Manager scans the linked 15 list of free blocks and stores a value in each block representing the total amount of free space scanned so far. The total amount of free space is stored in a free space field located within each free block. Preferably, the same space is used for the free hint fleld and the 20 rree space field. This value represents the amount each allocated block below each particular free block will be moved during compaction.
In steps 606-610, the Heap Manager determines the amount each allocated block of memory will be moved 25 during compaction and updates the handles to these blocks accordingly. A handle can be free or allocated; an allocated handle contains an indirect re~erence to an allocated block. Handles are stored in handle block 210 referenced in Figure 2B. In step 606, the Heap ~anager 3 0 scans the handle block and selects the next allocated handle, beginning with the first one.
In step 607, the ~eap Manager determines whether all of the handles have been selected. If all of the handles have not been selected, the process continues on 35 to step 608. In step 608, the Heap Manager selects the allocated block ref erenced by the selected handle . In step 609, the Heap Manager attempts to locate the f irst _ ~ WO 94/02898 'CI/US93/07021 2~ ~97~8 lg free block above the selected block. If there is no free block above the selected block, the process loops back to step 606 where the Heap Manager selects the next allocated handle. The Heap Manager locates the free block by f irst 5 def~mi n; nq which seqment contains the 5a~ e~ block.
The Heap Manager then searches the maximum free block array f or a non-null pointer entry ~_~ r L ~ n~ i nq to a segment above or ; n~ 3 i ng the segment that contains the s~1 ected block.
Once a non-null pointer entry is found, the Heap Manager searches the free list that is pointed to by the non-null pointer to locate the lowest address free block above the block ref erenced by the handle . Note that the free list at this time is the list of free blocks created 15 previously in step 601. Once the free block is located, in step 610, the Heap Manager updates the address stored in the s~l e-tPd handle by adding to it the value in the free space field of the free block minus any shift down factor. The Heap Manager repeats step 606 through 610 20 until all of the handles to the allocated blocks have been selected and updated.
Referring to Figure 68, in steps 611-613, the Heap Manaqer moves the allocated blocks to higher addresses, causing all of the free blocks to Ar~ Ate at 25 the bottom of the data block area. In step 611, the Heap Manager selects the next free block, starting with the ~irst one in the linked list generated in step 601. Each ~ree block contains a value in the free space field that indicates the amount of ~ree space above and including the 30 free block. In step 612, the Heap ~anager determines whether all of the free blocks have been scanned. If all of the free blocks have not been scanned, in step 613, the Heap Manager moves each allocated block in between the S~l aci ~ free block and the free block below it to new 35 higher adl.asses. A new address is calculated by adding the old address to the value stored in the free space field of the selected free block.
_ _ _ . _ _ . .. . _ . _ _ _ _ _ , WO 94/0289~ PCr/US93/07021 ~l ~ 9788 20 .
The Heap Nanager repeats steps 611-613 until all of the free blocks have been scanned and the allocated blocks have been moved upward the appropriate amount.
A~ter all of the free blocks have been scanned, in step 5 614, the Xeap Manager moves all the allocated blocks down to their final position as indicated by the shift down factor if any. Any resulting free space that has been ar~ Ated at the bottom of the data block area is added to the master block in step 615. In step 616, the size 10 tree and maximum free block array are reinitialized to re~lect that there are no longer any free blocks in the heap .
Figures 7A and 7B are schQatic diagrams used to illustrate an example of the compaction process. Figure 15 7A is a schQatic diagram of size tree 700, maximum free block array 710, data block area 730, and handle block 750 bef ore compaction, while Figure 7B is a schematic diagram of size tree 700, maximum free block array 710, data block area 730, master block 740, and handle block 750 after 20 compaction. Even though the handle biock is preferably located at the bottom of segment 0, for purposes of this ~xample, handle block 750 is shown without reference to a segment number. The dashed lines in data block area 730 represent segment boundaries, while the solid lines 25 ~LL ~.lL block boundaries. Data block area 730 is divided into 8 segments.
In this example, a reguesting program has ~ade an allocation request for a block of memory having size 10. Referring to Figure 7A, the allocation request has 30 ~ailed because the size of largest free block available is 6, as indicated by the root node 701 of the size tree 700.
Additionally, the master block was too small for the Heap ~Sana~er to transfer free space. Data block area 730 ~nrl~rlPc free blocks F0-F3 and allocated blocks A0-A8.
35 Handle block 750 i nrl~ Pc handles H0-H8, which identify the location of allocated blocks A0-A8, respectively. The size o~ each block is stored in a size field, which is the -~ WO 94102898 PCI/US93/07021 21 2 1 ~ 9 78~3 first field of each block. For example, the size of block A0 is 6.
The goal of c3~paction is to consolidate all of the free blocks in data block area 730 to add to the master block. To do this, allocated blocks A0-A7 will have to be physically moved to higher addresses.
Allocated block A8 will not be moved because there are no ~ree bloclcs located a~ove it. To determine the amount each allocated block must be moved, the Heap Nanaqer f irst scans all of the data blocks and creates a linked list of free blocks by linking together free blocks F0-F3 from the top of the data block area to the bottom. Each free block contains a pointer to the next lower free block. The pointer is pre~erably located a~ter the size f ield. The Heap Manager then scans the linked list of free blocks, storing a value in each block representing the cumulative amount of free space scanned so far. This value is stored in the free space f ield.
For example, the Heap Nanager stores 4 in the free space field Or rree block F3 because ~ree block F3 has size 4, and 4 is the amount of free space scannQd so far. The Heap Manager then stores 10 in the free space field of free block F2, which Le:~L~Sc:llLS the size of free block F3 plus the size of free block F2. The Heap Manager 2S stores 12 and 16 in the free space fields of free blocks F1 and F0, respectively. The value stored in the free space field of the last free block in the linked list of free blocks represents thQ total amount of free space in the data block area.
After de~Prm;n;~ the amount of ~ree space above and ;nr~ ;ng each free block and before moving each allocated block, the Heap Manager updates handles H0-H8.
As described above, a handle is an identif ier of an allocated block of memory. ~o update a handle to an allocated block, the ~eap Manager computes how much the address of the allocated block will change when the allocated block is moved. The value stored in the free WO 94/02898 PCr/US93/07021~
space field of a free block is the amount that each allocated block in between the free block and a next lower free blocX will have to be moved. For example, allocated blocks A3-A5 will be moved up 10, the value stored in the 5 free space field of free block F2 minus the shift down amount, which in this case is 0.
The Xeap Manager selects the f irst handle H5, which is a handle to allocated block A5. Based on the address of block A5, the Heap Manager derarminas which 10 segment contains block A5. Segment 3 contains bloc3c A5, because block A5 starts at address 3 0 . Next, the Heap Manager looks at entry 723 in maximum free block array 710 (entry 723 ~ u~ ul-ds to segment 3) to determine if there are any free blocks in segment 3. Entry 723 contains a 15 null pointer, indicating there are no free blocks in segment 3.
The Heap Nanager then searches maximum free block array 710 starting with the entry for segment 4, searching f or the f irst non-null pointer entry . Entry 20 724, c, - -" , l;n~ to segment 4 contains a non-null pointer entry. The Xeap Manger searches the linked list of free blocks, starting with the free block pointed to by entry 724, searching for the free block whose address is closest to and greater than the address of allocated block 25 A5. Entry 724 points to free block F2. Free block F2 is located above allocated block A5. The Heap Manager updates handle X5 by adding the value stored in the free space field of free block F2 (10) to the address of allocated block A5 (30), and then subtracting any shift 30 down amount. The result is 40, which will be the address of allocated block A5 after it is moved. The new address is stored in handle X5, as shown in Figure 7B. The above process is repeated to update the rr-~ i n i n~ handles .
After all of the handles have been updated, the 35 Heap Manager physically moves each allocated block. The Xeap Manager selects the first free block F3 in the linked list of free blocks, and determines which allocated blocks ~ WO 94/02898 PCr~US93/07021 23 21 1~788 are between free block F3 and the next free block in the linked list, free block F2. The Heap ~anager then moves all of the allocated blocks in between free blocks F3 and F2 up by the amount stored in the free space f ield of free 5 block F3. Therefore, allocated blocks A7 and A6 are moved up 4 units. The Heap Nanager then selects the next ~ree block F2. Because free block F2 contains the value lO in its free space field, all of the allocated blocks between free blocks P2 and Fl (allocated blocks A5-A3) are moved lO up lO units. This process continues until all of the allocated blocks have been moved up the appropriate amount. Note that allocated block A8 is not moved because there is no free space above it. If the heap is being made smaller, data blocks A0-A8 are moved down by the 15 shi~t down amount.
Figure 7B shows the results of the compaction.
Data block area 730 contains allocated blocks A0-A8 with no free space in between the allocated blocks. Free blocks F0-F3 of Figure 7A have been consolidated into 20 master block 740 of Figure 78. Handle block 750 contains handles H0-H8. Size tree 700 and maximum free block array 710 have been reini~ od because data block area 730 does not contain any free blocks.
Debuqqinq. The present invention also provides 25 a method for locating pointers that have not been correctly updated by a requesting program. Requesting ~IL~I~LC~1..3 ~ use pointers to identify allocated blocks. To ensure that these pointers are properly updated when an allocated block is moved, the present 30 invention provides a debugging mode in which allocated blocks are automatically moved . In ef f ect, the heap is "shaken" to force any pointer errors to surface. Nhen heap shake is enabled, the Heap ~Sanager moves all data blocks a prede~-min~ amount after satisfying an 35 allocation request. Nhen each allocated block is moved, a routine (optionally supplied by the requesting program) is inYoked to update any pointers the requesting program has to the moved block.
After all blocks are moved the maximum amount, the blocks are moved back to their starting positions.
S IIJV~ L space for this "heap shake" is preferably maintained in the end block, located above the data block area. The end block is never allocated to a requesting program and the master block is never reduced beyond what is currently necessary to support a heap shake. 3uring each "shake" all of the internal free block pointers are updated by scanning free blocks and adding or subtracting the predetPrmi n~d shake amount. Then each data block (allocated and free) is moved to its new position.
Lastly, all the handles to the allocated blocks are updated to their new values by adding or subtracting a constant. To prevent having to update the size tree, the maximum free block array, and the free lists for each segment, segment addresses are calculated from an adjustable base which is updated after each heap shake.
Although the methods and systems of the present invention have been described in terms of a preferred ~-mho~ , it is not intended that the invention be limited to this ~mho~ r t . Modif ications within the spirit of the invention will be apparent to those skilled in the art. The scope of the present invention is def ined only by the claims that foll~w.
Claims (24)
1. A method in a computer system of managing the allocation, and freeing of blocks within a heap, the heap having a plurality of free blocks and a plurality of allocated blocks and being logically subdivided into a plurality of segments, the method comprising:
providing a free list for each segment in the heap, each free list comprising a list of the free blocks in the segment;
providing a free block array, the free block array having a plurality of entries, each entry corresponding to a segment and containing a pointer to the free list for the corresponding segment;
providing a size tree, the size tree having a plurality of non-leaf nodes and a plurality of leaf notes, each non-leaf node having a value such that the value of each non-leaf node is equal to the largest value of its child nodes, and each leaf node corresponding to an entry in the free block array and containing a value indicating the size of the largest free block in the free list pointed to by the entry;
in response to a block allocation request to allocate a block of a requested size, searching the size tree to locate a segment containing a free block that satisfies the block allocation request, and searching the free list corresponding to the selected segment to select the free block that satisfies the block allocation request; and in response to a block freeing request to free an allocated block, adding the allocated block to the free list for the segment that contains the allocated block.
providing a free list for each segment in the heap, each free list comprising a list of the free blocks in the segment;
providing a free block array, the free block array having a plurality of entries, each entry corresponding to a segment and containing a pointer to the free list for the corresponding segment;
providing a size tree, the size tree having a plurality of non-leaf nodes and a plurality of leaf notes, each non-leaf node having a value such that the value of each non-leaf node is equal to the largest value of its child nodes, and each leaf node corresponding to an entry in the free block array and containing a value indicating the size of the largest free block in the free list pointed to by the entry;
in response to a block allocation request to allocate a block of a requested size, searching the size tree to locate a segment containing a free block that satisfies the block allocation request, and searching the free list corresponding to the selected segment to select the free block that satisfies the block allocation request; and in response to a block freeing request to free an allocated block, adding the allocated block to the free list for the segment that contains the allocated block.
2. The method of claim 1 wherein the size tree is a binary tree and the number of segments is a power of two.
3. The method of claim 1 wherein the step of providing a free list for each segment includes providing a linked free list for each segment, each linked free list comprising a linked list of the free blocks in the segment.
4. The method of claim 3 wherein the step of providing a linked free list includes providing an ordered linked free list for each segment, each ordered linked free list comprising an ordered linked list of the free blocks in the segment such that the free blocks are ordered according to size.
5. The method of claim 1 wherein the segments of the heap are ordered from a low segment to a high segment and the step of searching the size tree includes searching the size tree to locate the highest segment that contains a free block having a size large enough to satisfy the request.
6. The method of claim 1 wherein the segments of the heap are ordered from a high segment to a low segment and the step of searching the size tree includes searching the size tree to locate the lowest segment that contains a free block having a size large enough to satisfy the request.
7. The method of claim 1 wherein the step of searching the size tree includes the steps of:
traversing the size tree to select a leaf node that contains a value large enough to satisfy the request;
selecting a free block array entry corresponding to the selected leaf node whichpoints to a free list that contains a free block large enough to satisfy the request;
selecting a free block from the free list pointed to by the selected free block array entry, the free block being large enough to satisfy the request;
removing the selected free block from the free list; and updating the size tree and the free block array to reflect the removal of the selected free block from the free list.
traversing the size tree to select a leaf node that contains a value large enough to satisfy the request;
selecting a free block array entry corresponding to the selected leaf node whichpoints to a free list that contains a free block large enough to satisfy the request;
selecting a free block from the free list pointed to by the selected free block array entry, the free block being large enough to satisfy the request;
removing the selected free block from the free list; and updating the size tree and the free block array to reflect the removal of the selected free block from the free list.
8. A memory management system for managing a computer memory comprising:
a block area comprising a plurality of free blocks and a plurality of allocated blocks, the block area being subdivided into a plurality of segments;
a free list for each segment, wherein the free list is a list of the free blocks in the segment;
a free block array having an entry corresponding to each segment in the block area, each entry containing a pointer to the free list for the corresponding segment;
a size tree comprising at least one non-leaf node and a plurality of leaf nodes,each non-leaf node having a plurality of child nodes, each node having a value, each leaf node corresponding to a plurality of entries in the free block array and having a value indicating the size of the largest free block in the segments corresponding to the plurality of entries, wherein the value of each non-leaf node is equal to the largest value of its child nodes; and a memory manager for traversing the size tree to select an entry in the free block array, following the pointer stored in the selected entry to a free list, and searching the free list to locate a free block having a requested size.
a block area comprising a plurality of free blocks and a plurality of allocated blocks, the block area being subdivided into a plurality of segments;
a free list for each segment, wherein the free list is a list of the free blocks in the segment;
a free block array having an entry corresponding to each segment in the block area, each entry containing a pointer to the free list for the corresponding segment;
a size tree comprising at least one non-leaf node and a plurality of leaf nodes,each non-leaf node having a plurality of child nodes, each node having a value, each leaf node corresponding to a plurality of entries in the free block array and having a value indicating the size of the largest free block in the segments corresponding to the plurality of entries, wherein the value of each non-leaf node is equal to the largest value of its child nodes; and a memory manager for traversing the size tree to select an entry in the free block array, following the pointer stored in the selected entry to a free list, and searching the free list to locate a free block having a requested size.
9. The memory management system of claim 8 wherein the block area is subdivided into 2n segments.
10. The memory management system of claim 8 wherein the size tree is a binary tree.
11. The memory management system of claim 8 wherein the free list is a linked list.
12. The memory management system of claim 8 wherein the blocks that make up each free list are positioned within the free list according to block size.
13. The memory management system of claim 8 wherein each allocated block has a corresponding handle, and including a handle mapping table to map each handle to the corresponding allocated block.
14. The memory management system of claim 13 wherein the handle mapping table is stored in an allocated block.
15. A computer memory management system comprising:
a heap of memory logically subdivided into segments, each segment including a plurality of free blocks and allocated blocks, each free block and allocated block having a block size;
a free list for each segment, each free list comprising a linked list of free blocks in that segment, the free blocks being ordered in the link list by block size;
a free block array having one entry for each segment in the heap, each entry comprising a pointer to a first free block within the free list for that segment; and a size tree for organizing block sizes of first free blocks, the size tree having non-leaf nodes and leaf nodes, each non-leaf node having a plurality of child nodes, each non-leaf node having a value such that the value of each non-leaf node is equal to the largest value of its child nodes, and each leaf node corresponding to an entry in the free block array and having a value indicating the size of the largest first free block in the segment corresponding to the entry.
a heap of memory logically subdivided into segments, each segment including a plurality of free blocks and allocated blocks, each free block and allocated block having a block size;
a free list for each segment, each free list comprising a linked list of free blocks in that segment, the free blocks being ordered in the link list by block size;
a free block array having one entry for each segment in the heap, each entry comprising a pointer to a first free block within the free list for that segment; and a size tree for organizing block sizes of first free blocks, the size tree having non-leaf nodes and leaf nodes, each non-leaf node having a plurality of child nodes, each non-leaf node having a value such that the value of each non-leaf node is equal to the largest value of its child nodes, and each leaf node corresponding to an entry in the free block array and having a value indicating the size of the largest first free block in the segment corresponding to the entry.
16. The computer system of claim 15 wherein the heap is subdivided into 2n segments having a uniform size.
17. A method of dynamically managing a heap in response to instructions from a requesting program, the heap having a plurality of free blocks and a plurality of allocated blocks and being logically subdivided into a plurality of segments, the number of segments being a power of two and each segment having a free list, the free list linking the free blocks in the segment and being accessible through a size tree and a free block list, the free block list having a plurality of entries, each entry corresponding to a segment and pointing to the free list for the segment, the size tree having a root node, a plurality of child nodes, and a plurality of leaf nodes, each node having a value such that the nodes of the size tree are arranged as a complete binary tree wherein the value of each node is not exceeded by the value of its child nodes, and each leaf node corresponding to two entries in the free block list and having a value indicating the size of the largest free block in the segments corresponding to the entries, the method comprising:
selecting a free block of memory of a requested size from the heap for allocation to a requesting program, wherein the free block is selected by searching the size tree and free block list to locate a segment that contains a free block that will satisfy the request and then searching the free list corresponding to the selected segment to locate the smallest free block that satisfies the request;
freeing an allocated block of memory based on instructions from a requesting program and consolidating the newly freed block with any free blocks that are located immediately above and below the newly freed block; and creating a free block when the heap does not contain a free block of the requested size, wherein the created free block has a size that is greater than or equal to the requested size.
selecting a free block of memory of a requested size from the heap for allocation to a requesting program, wherein the free block is selected by searching the size tree and free block list to locate a segment that contains a free block that will satisfy the request and then searching the free list corresponding to the selected segment to locate the smallest free block that satisfies the request;
freeing an allocated block of memory based on instructions from a requesting program and consolidating the newly freed block with any free blocks that are located immediately above and below the newly freed block; and creating a free block when the heap does not contain a free block of the requested size, wherein the created free block has a size that is greater than or equal to the requested size.
18. The method of claim 17 wherein the step of creating a free block includes the step of compacting allocated blocks into higher memory addresses thereby accumulating free blocks into lower memory addresses, the accumulated free blocks being consolidated to create one free block.
19. The method of claim 17 wherein the step of creating a free block of a requested size includes the step of enlarging the heap.
20. The method of claim 19 wherein the step of selecting a free block of memory for allocation includes the additional steps of:
providing a request for a block having a certain size;
searching the size tree and selecting a leaf node that contains a value that is large enough to satisfy the request;
selecting a free block list entry corresponding to the selected leaf node which points to a free list that contains a free block large enough to satisfy the request;
selecting a free block from the free list pointed to by the selected free block list entry that best fits the request;
removing the selected free block from its free list; and updating the size tree and free block list to reflect the removal of the selected free block from its free list.
providing a request for a block having a certain size;
searching the size tree and selecting a leaf node that contains a value that is large enough to satisfy the request;
selecting a free block list entry corresponding to the selected leaf node which points to a free list that contains a free block large enough to satisfy the request;
selecting a free block from the free list pointed to by the selected free block list entry that best fits the request;
removing the selected free block from its free list; and updating the size tree and free block list to reflect the removal of the selected free block from its free list.
21. The method of claim 17 wherein each entry of the free block list contains a pointer to a free block that has the largest size in a segment.
22. The method of claim 17 wherein the plurality of free blocks that comprises the heap includes a master block and wherein the step of selecting a block of memory of a requested size includes the additional steps of:
(a) when the requested size is less than or equal to the value contained in the root node of the size tree (i) selecting the rightmost leaf node of the size tree that contains a value that is greater than or equal to the requested size, (ii) selecting a free block list entry that corresponds to the selected leaf node such that the free list pointed to by the entry contains a free block that is greater than or equal to the requested size, (iii) selecting the free list pointed to by the selected free block list entry, (iv) selecting the smallest free block in the selected free list whose size is greater than or equal to the requested size, (v) removing the selected free block from the selected free list, (vi) allocating a portion of the selected free block to the requesting computer program, wherein the portion is equal to the requested size, (vii) adding the unallocated portion of the selected free block to the selected free list, and (viii) updating the size tree and free block list when the selected free list is modified; and (b) when the requested size is greater than the value contained in the root node of the size tree (i) consolidating the master block with any free blocks immediately above it, and (ii) allocating a portion of the master block to the requesting computer program, wherein the portion is equal to the requested size.
(a) when the requested size is less than or equal to the value contained in the root node of the size tree (i) selecting the rightmost leaf node of the size tree that contains a value that is greater than or equal to the requested size, (ii) selecting a free block list entry that corresponds to the selected leaf node such that the free list pointed to by the entry contains a free block that is greater than or equal to the requested size, (iii) selecting the free list pointed to by the selected free block list entry, (iv) selecting the smallest free block in the selected free list whose size is greater than or equal to the requested size, (v) removing the selected free block from the selected free list, (vi) allocating a portion of the selected free block to the requesting computer program, wherein the portion is equal to the requested size, (vii) adding the unallocated portion of the selected free block to the selected free list, and (viii) updating the size tree and free block list when the selected free list is modified; and (b) when the requested size is greater than the value contained in the root node of the size tree (i) consolidating the master block with any free blocks immediately above it, and (ii) allocating a portion of the master block to the requesting computer program, wherein the portion is equal to the requested size.
23. The method of claim 17 wherein each block in the heap contains a count field at beginning of the block and a free hint field at the end of the block, the size of the block being stored in the count field and an allocation indicator being stored in the free hint field, and wherein the step of freeing a block of memory includes the additional steps of:
(a) providing the address of a current block wherein the current block is the block to be freed;
(b) examining the free hint field of a lower block, wherein the lower block is located immediately below the current block;
(c) when the free hint field of the lower block contains an allocation indicator that indicates the block is free (i) examining the free list corresponding to a current segment, wherein the current segment is the segment that contains the current block, (ii) determining whether the lower block is in the free list corresponding to the current segment, (iii) when the lower block is not in the free list corresponding to the current segment, (1) searching the free block list backwards from the entry for the current segment until a non-zero entry or the beginning of the free block list is found, (2) if a non-zero entry is found in the free block list, selecting the free list pointed to by the non-zero entry, (3) determining whether the lower block is in the selected free list, (iv) when the lower block is in a free list, consolidating the current block with the lower block and updating the free list that contains the lower block;
(d) examining the count field of an upper block wherein the upper block is immediately above the current block;
(e) when the upper block is free, removing the upper block from the free list associated with the upper block;
(f) consolidating the current block with the upper block; and (g) adding the current block to the free list corresponding to the consolidated blocks and the size tree.
(a) providing the address of a current block wherein the current block is the block to be freed;
(b) examining the free hint field of a lower block, wherein the lower block is located immediately below the current block;
(c) when the free hint field of the lower block contains an allocation indicator that indicates the block is free (i) examining the free list corresponding to a current segment, wherein the current segment is the segment that contains the current block, (ii) determining whether the lower block is in the free list corresponding to the current segment, (iii) when the lower block is not in the free list corresponding to the current segment, (1) searching the free block list backwards from the entry for the current segment until a non-zero entry or the beginning of the free block list is found, (2) if a non-zero entry is found in the free block list, selecting the free list pointed to by the non-zero entry, (3) determining whether the lower block is in the selected free list, (iv) when the lower block is in a free list, consolidating the current block with the lower block and updating the free list that contains the lower block;
(d) examining the count field of an upper block wherein the upper block is immediately above the current block;
(e) when the upper block is free, removing the upper block from the free list associated with the upper block;
(f) consolidating the current block with the upper block; and (g) adding the current block to the free list corresponding to the consolidated blocks and the size tree.
24. The method of claim 21 wherein each block in the heap contains a count field and a free hint field, the size of the block being stored in the count field and an allocation indicator being stored in the free hint field, wherein a first segment is located at a lower memory address and a last segment is located at a higher memory address, and wherein the step of freeing a block of memory includes the additional steps of:
(a) providing the address of a current block, wherein the current block is the block to be freed;
(b) examining the free hint field of a lower block, wherein the lower block is located immediately below the current block;
(c) when the free hint field of the lower block contains an allocation indicator that indicates the lower block might be free, (i) searching the free lists corresponding to the current segment and the segments below the current segment for the lower block, (ii) if the lower block is found in one of the searched free lists, consolidating the current block with the lower block and updating the free list that contains the lower block, (d) examining the count field of the block immediately above the current block wherein the block immediately above the current block is known as the upper block, to determine whether the upper block is free, wherein the lowest bit of the count field contains an indicator indicating if the block is free or allocated;
(e) when the upper block is free, consolidating the current block with the upper block and removing the upper block from its free list; and (f) updating the free list for the current segment.
(a) providing the address of a current block, wherein the current block is the block to be freed;
(b) examining the free hint field of a lower block, wherein the lower block is located immediately below the current block;
(c) when the free hint field of the lower block contains an allocation indicator that indicates the lower block might be free, (i) searching the free lists corresponding to the current segment and the segments below the current segment for the lower block, (ii) if the lower block is found in one of the searched free lists, consolidating the current block with the lower block and updating the free list that contains the lower block, (d) examining the count field of the block immediately above the current block wherein the block immediately above the current block is known as the upper block, to determine whether the upper block is free, wherein the lowest bit of the count field contains an indicator indicating if the block is free or allocated;
(e) when the upper block is free, consolidating the current block with the upper block and removing the upper block from its free list; and (f) updating the free list for the current segment.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US91959192A | 1992-07-24 | 1992-07-24 | |
| US07/919,591 | 1992-07-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2119788C true CA2119788C (en) | 1996-12-31 |
Family
ID=25442342
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002119788A Expired - Lifetime CA2119788C (en) | 1992-07-24 | 1993-07-26 | Computer method and system for allocating and freeing memory |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5561786A (en) |
| EP (1) | EP0606461B1 (en) |
| JP (1) | JPH06511582A (en) |
| CA (1) | CA2119788C (en) |
| DE (1) | DE69327089T2 (en) |
| WO (1) | WO1994002898A1 (en) |
Families Citing this family (157)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5682497A (en) * | 1993-09-28 | 1997-10-28 | Intel Corporation | Managing file structures for a flash memory file system in a computer |
| US6131150A (en) * | 1993-10-05 | 2000-10-10 | Digital Equipment Corporation | Scaled memory allocation system |
| ES2176214T3 (en) * | 1994-09-19 | 2002-12-01 | Siemens Ag | MEMORY ADMINISTRATION SYSTEM OF A COMPUTER SYSTEM. |
| CA2136154C (en) * | 1994-11-18 | 1999-08-24 | Jay William Benayon | User control of multiple memory heaps |
| JP3464836B2 (en) * | 1995-01-19 | 2003-11-10 | 富士通株式会社 | Memory management device for storage device |
| US5897660A (en) * | 1995-04-07 | 1999-04-27 | Intel Corporation | Method for managing free physical pages that reduces trashing to improve system performance |
| US5787447A (en) * | 1995-05-08 | 1998-07-28 | Sun Microsystems, Inc. | Memory allocation maintaining ordering across multiple heaps |
| US5742797A (en) * | 1995-08-11 | 1998-04-21 | International Business Machines Corporation | Dynamic off-screen display memory manager |
| US5897662A (en) * | 1995-08-18 | 1999-04-27 | International Business Machines Corporation | Pseudo-random address generation mechanism that reduces address translation time |
| US5835959A (en) * | 1995-12-01 | 1998-11-10 | Sand Technology Systems International, Inc. | Memory management system and method using dual indexing structures |
| WO1997008622A1 (en) * | 1995-08-31 | 1997-03-06 | Sand Technology Systems International, Inc. | Memory management system and method |
| US6081623A (en) * | 1995-10-11 | 2000-06-27 | Citrix Systems, Inc. | Method for lossless bandwidth compression of a series of glyphs |
| US6016535A (en) * | 1995-10-11 | 2000-01-18 | Citrix Systems, Inc. | Method for dynamically and efficiently caching objects by subdividing cache memory blocks into equally-sized sub-blocks |
| US7146479B2 (en) * | 2001-07-18 | 2006-12-05 | City U Research Limited | Method and apparatus of storage allocation/de-allocation in object-oriented programming environment |
| US6427147B1 (en) | 1995-12-01 | 2002-07-30 | Sand Technology Systems International | Deletion of ordered sets of keys in a compact O-complete tree |
| US5758353A (en) * | 1995-12-01 | 1998-05-26 | Sand Technology Systems International, Inc. | Storage and retrieval of ordered sets of keys in a compact 0-complete tree |
| US5689707A (en) * | 1995-12-04 | 1997-11-18 | Ncr Corporation | Method and apparatus for detecting memory leaks using expiration events and dependent pointers to indicate when a memory allocation should be de-allocated |
| US5832526A (en) * | 1996-01-24 | 1998-11-03 | Symantec Corporation | Method and apparatus using slack area of file storage structures for file reconstruction |
| US5778392A (en) * | 1996-04-01 | 1998-07-07 | Symantec Corporation | Opportunistic tile-pulling, vacancy-filling method and apparatus for file-structure reorganization |
| US5784699A (en) * | 1996-05-24 | 1998-07-21 | Oracle Corporation | Dynamic memory allocation in a computer using a bit map index |
| US6057857A (en) | 1996-06-12 | 2000-05-02 | Citrix Systems, Inc. | Method for the lossless compression of lines in a distributed computer system |
| US5978893A (en) * | 1996-06-19 | 1999-11-02 | Apple Computer, Inc. | Method and system for memory management |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US5848246A (en) | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US6424991B1 (en) | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| US6038590A (en) | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US5987245A (en) | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US5999972A (en) | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US6304893B1 (en) | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US6115799A (en) * | 1996-07-19 | 2000-09-05 | Canon Kabushiki Kaisha | Information processing apparatus and associated method for managing a memory using a next fit and for reducing a memory fragmentation problem |
| US5949972A (en) * | 1996-08-23 | 1999-09-07 | Compuware Corporation | System for memory error checking in an executable |
| US6092168A (en) * | 1996-10-25 | 2000-07-18 | Hewlett-Packard Co. | Data storage system and method for deallocating space by writing and detecting a predefined data pattern |
| US5930827A (en) * | 1996-12-02 | 1999-07-27 | Intel Corporation | Method and apparatus for dynamic memory management by association of free memory blocks using a binary tree organized in an address and size dependent manner |
| US5930829A (en) * | 1997-03-31 | 1999-07-27 | Bull Hn Information Systems Inc. | Dynamic memory allocation for a random access memory employing separately stored space allocation information using a tree structure |
| US5987580A (en) * | 1997-04-04 | 1999-11-16 | Oracle Corporation | Serially reusable execution memory |
| US5903899A (en) * | 1997-04-23 | 1999-05-11 | Sun Microsystems, Inc. | System and method for assisting exact Garbage collection by segregating the contents of a stack into sub stacks |
| US5900001A (en) * | 1997-04-23 | 1999-05-04 | Sun Microsystems, Inc. | Method and apparatus for optimizing exact garbage collection using a bifurcated data structure |
| US6101580A (en) * | 1997-04-23 | 2000-08-08 | Sun Microsystems, Inc. | Apparatus and method for assisting exact garbage collection by using a stack cache of tag bits |
| US5911144A (en) * | 1997-04-23 | 1999-06-08 | Sun Microsystems, Inc. | Method and apparatus for optimizing the assignment of hash values to nodes residing in a garbage collected heap |
| US5848423A (en) * | 1997-04-23 | 1998-12-08 | Sun Microsystems, Inc. | Garbage collection system and method for locating root set pointers in method activation records |
| US6038572A (en) * | 1997-04-23 | 2000-03-14 | Sun Microsystems, Inc. | Method and apparatus for localizing nodes in a garbage collected carded heap |
| US5920876A (en) * | 1997-04-23 | 1999-07-06 | Sun Microsystems, Inc. | Performing exact garbage collection using bitmaps that identify pointer values within objects |
| US5930807A (en) * | 1997-04-23 | 1999-07-27 | Sun Microsystems | Apparatus and method for fast filtering read and write barrier operations in garbage collection system |
| US5893121A (en) * | 1997-04-23 | 1999-04-06 | Sun Microsystems, Inc. | System and method for swapping blocks of tagged stack entries between a tagged stack cache and an untagged main memory storage |
| US5909579A (en) * | 1997-04-23 | 1999-06-01 | Sun Microsystems, Inc. | Method and apparatus for encoding and decoding delta encoded information to locate live pointers in program data stacks |
| US6115782A (en) * | 1997-04-23 | 2000-09-05 | Sun Micosystems, Inc. | Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value |
| US5903900A (en) * | 1997-04-23 | 1999-05-11 | Sun Microsystems, Inc. | Method and apparatus for optimizing exact garbage collection of array nodes in a carded heap |
| US5915255A (en) * | 1997-04-23 | 1999-06-22 | Sun Microsystems, Inc. | Method and apparatus for referencing nodes using links |
| US6199075B1 (en) | 1997-05-30 | 2001-03-06 | Sun Microsystems, Inc. | Method and apparatus for generational garbage collection of a heap memory shared by multiple processors |
| US6094664A (en) * | 1997-05-30 | 2000-07-25 | Sun Microsystems | Method and apparatus for optimizing the null pointer exception in an object-oriented programming environment with statically typed variables |
| US6105040A (en) * | 1997-06-30 | 2000-08-15 | Sun Microsystems, Inc. | Method and apparatus for managing stored objects |
| US6088764A (en) | 1997-07-14 | 2000-07-11 | International Business Machines Corporation | Method and apparatus for reducing space allocation failures in storage management systems |
| GB9717718D0 (en) * | 1997-08-22 | 1997-10-29 | Philips Electronics Nv | Memory management with compaction of data blocks |
| US6173291B1 (en) * | 1997-09-26 | 2001-01-09 | Powerquest Corporation | Method and apparatus for recovering data from damaged or corrupted file storage media |
| US6047125A (en) * | 1997-10-01 | 2000-04-04 | Sun Microsystems, Inc. | Garbage collection system for improved use of memory by removal of reference conflicts |
| US6076151A (en) | 1997-10-10 | 2000-06-13 | Advanced Micro Devices, Inc. | Dynamic memory allocation suitable for stride-based prefetching |
| US6065019A (en) * | 1997-10-20 | 2000-05-16 | International Business Machines Corporation | Method and apparatus for allocating and freeing storage utilizing multiple tiers of storage organization |
| US6088777A (en) * | 1997-11-12 | 2000-07-11 | Ericsson Messaging Systems, Inc. | Memory system and method for dynamically allocating a memory divided into plural classes with different block sizes to store variable length messages |
| US6018789A (en) * | 1997-11-24 | 2000-01-25 | Western Digital Corporation | Disk drive with cache segment providing adaptively managed chunks |
| US6490670B1 (en) * | 1998-04-24 | 2002-12-03 | International Business Machines Corporation | Method and apparatus for efficiently allocating objects in object oriented systems |
| GB9813592D0 (en) * | 1998-06-25 | 1998-08-19 | Philips Electronics Nv | Dynamic memory space allocation |
| US6510504B2 (en) | 1998-06-29 | 2003-01-21 | Oracle Corporation | Methods and apparatus for memory allocation for object instances in an object-oriented software environment |
| US6253215B1 (en) | 1998-08-17 | 2001-06-26 | Sun Microsystems | Method, apparatus, and article of manufacture for facilitating resource management for applications having two types of program code |
| US6412053B2 (en) * | 1998-08-26 | 2002-06-25 | Compaq Computer Corporation | System method and apparatus for providing linearly scalable dynamic memory management in a multiprocessing system |
| DE19841447A1 (en) * | 1998-09-10 | 2000-03-16 | Siemens Ag | Method of transferring data via several parallel interfaces |
| US6396838B1 (en) * | 1998-09-28 | 2002-05-28 | Ascend Communications, Inc. | Management of free space in an ATM virtual connection parameter table |
| GB2342470A (en) * | 1998-10-09 | 2000-04-12 | Ibm | A memory management system and method for a data processing system |
| US6408368B1 (en) | 1999-06-15 | 2002-06-18 | Sun Microsystems, Inc. | Operating system page placement to maximize cache data reuse |
| US6366994B1 (en) | 1999-06-22 | 2002-04-02 | Sun Microsystems, Inc. | Cache aware memory allocation |
| US6430665B1 (en) * | 1999-06-25 | 2002-08-06 | Sun Microsystems, Inc. | System and method for heuristically allocating memory |
| US6381738B1 (en) * | 1999-07-16 | 2002-04-30 | International Business Machines Corporation | Method for optimizing creation and destruction of objects in computer programs |
| US6629111B1 (en) * | 1999-10-13 | 2003-09-30 | Cisco Technology, Inc. | Memory allocation system |
| US6662310B2 (en) | 1999-11-10 | 2003-12-09 | Symantec Corporation | Methods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data |
| US6631480B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods and systems for protecting data from potential corruption by a crashed computer program |
| US6630946B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods for automatically locating data-containing windows in frozen applications program and saving contents |
| JP4565793B2 (en) * | 1999-12-10 | 2010-10-20 | エスエイテック・グループ・エー・ビー・リミテッド・ライアビリティ・カンパニー | Method and apparatus for longest match address lookup |
| US6742083B1 (en) | 1999-12-14 | 2004-05-25 | Genesis Microchip Inc. | Method and apparatus for multi-part processing of program code by a single processor |
| US6728853B1 (en) | 1999-12-14 | 2004-04-27 | Genesis Microchip Inc. | Method of processing data utilizing queue entry |
| US6775757B1 (en) | 1999-12-14 | 2004-08-10 | Genesis Microchip Inc. | Multi-component processor |
| US6920543B1 (en) * | 1999-12-14 | 2005-07-19 | Genesis Microchip, Inc. | Method and apparatus for performing distributed processing of program code |
| US6738884B1 (en) | 1999-12-14 | 2004-05-18 | Genesis Microchip Inc. | Method and apparatus for processing data with semaphores |
| US6539464B1 (en) * | 2000-04-08 | 2003-03-25 | Radoslav Nenkov Getov | Memory allocator for multithread environment |
| US6374340B1 (en) * | 2000-04-14 | 2002-04-16 | Motorola, Inc. | Method of managing memory for a PCI bus |
| US6606682B1 (en) * | 2000-04-19 | 2003-08-12 | Western Digital Technologies, Inc. | Cluster-based cache memory allocation |
| US6601137B1 (en) * | 2000-04-19 | 2003-07-29 | Western Digital Technologies, Inc. | Range-based cache control system and method |
| US6453403B1 (en) * | 2000-05-19 | 2002-09-17 | Sun Microsystems, Inc. | System and method for memory management using contiguous fixed-size blocks |
| US6594749B1 (en) * | 2000-05-19 | 2003-07-15 | Sun Microsystems, Inc. | System and method for memory management using fixed-size blocks |
| AU2001274972A1 (en) | 2000-05-26 | 2001-12-11 | Citrix Systems, Inc. | Method and system for efficiently reducing graphical display data for transmission over a low bandwidth transport protocol mechanism |
| US6971097B1 (en) * | 2000-06-09 | 2005-11-29 | Sun Microsystems, Inc. | Method and apparatus for implementing concurrently running jobs on an extended virtual machine using different heaps managers |
| US6880064B1 (en) * | 2000-06-21 | 2005-04-12 | Mosaid Technologies, Inc. | Method and apparatus for physical width expansion of a longest prefix match lookup table |
| AU2001293509A1 (en) * | 2000-10-04 | 2002-04-15 | Bullant Technology Pty Ltd | Data processing structure |
| US6697971B1 (en) * | 2000-10-24 | 2004-02-24 | Hewlett-Packard Development Company, L.P. | System and method for detecting attempts to access data residing outside of allocated memory |
| US6499094B1 (en) * | 2001-09-14 | 2002-12-24 | Unisys Corporation | Management of memory heap space for data files accessible to programs operating in different addressing modes |
| US7409517B2 (en) * | 2001-10-01 | 2008-08-05 | Oracle International Corporation | Dynamic and automatic memory management |
| US7499960B2 (en) | 2001-10-01 | 2009-03-03 | Oracle International Corporation | Adaptive memory allocation |
| US7028158B1 (en) | 2001-11-02 | 2006-04-11 | Beatty And Company Computing, Inc. | Storage virtualization engine |
| TW580619B (en) * | 2002-04-03 | 2004-03-21 | Via Tech Inc | Buffer control device and the management method |
| US7330956B1 (en) * | 2002-04-16 | 2008-02-12 | Emc Corporation | Bucket based memory allocation |
| US9344235B1 (en) * | 2002-06-07 | 2016-05-17 | Datacore Software Corporation | Network managed volumes |
| US6985916B2 (en) * | 2002-08-29 | 2006-01-10 | International Business Machines Corporation | Method, system, and article of manufacture for returning physical volumes |
| US6954768B2 (en) * | 2002-08-29 | 2005-10-11 | International Business Machines Corporation | Method, system, and article of manufacture for managing storage pools |
| KR20050057059A (en) * | 2002-08-30 | 2005-06-16 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | Dynamic memory management |
| US8060680B2 (en) * | 2002-09-16 | 2011-11-15 | Hewlett-Packard Development Company, L.P. | Method of allocating memory |
| US7010555B2 (en) * | 2002-10-17 | 2006-03-07 | International Business Machines Corporation | System and method for compacting a computer system heap |
| CN100422932C (en) * | 2002-12-31 | 2008-10-01 | 上海科泰世纪科技有限公司 | Processing method for self discribing data object |
| US7032090B2 (en) * | 2003-04-08 | 2006-04-18 | International Business Machines Corporation | Method, system, and apparatus for releasing storage in a fast replication environment |
| US7124272B1 (en) | 2003-04-18 | 2006-10-17 | Symantec Corporation | File usage history log for improved placement of files in differential rate memory according to frequency of utilizations and volatility of allocation space |
| CA2426619A1 (en) * | 2003-04-25 | 2004-10-25 | Ibm Canada Limited - Ibm Canada Limitee | Defensive heap memory management |
| CN100343826C (en) * | 2003-04-29 | 2007-10-17 | 华为技术有限公司 | Method for implementing memory management |
| US7827375B2 (en) * | 2003-04-30 | 2010-11-02 | International Business Machines Corporation | Defensive heap memory management |
| US7356655B2 (en) * | 2003-05-15 | 2008-04-08 | International Business Machines Corporation | Methods, systems, and media for managing dynamic storage |
| US6954826B2 (en) * | 2003-05-21 | 2005-10-11 | Freescale Semiconductor, Inc. | Read access and storage circuitry read allocation applicable to a cache |
| US7069402B2 (en) * | 2003-06-02 | 2006-06-27 | International Business Machines Corporation | Host-independent incremental backup method, apparatus, and system |
| KR100503093B1 (en) * | 2003-08-16 | 2005-07-21 | 삼성전자주식회사 | Method and apparatus managing a memory |
| US7792866B2 (en) * | 2003-08-25 | 2010-09-07 | International Business Machines Corporation | Method and system for querying structured documents stored in their native format in a database |
| US8150818B2 (en) * | 2003-08-25 | 2012-04-03 | International Business Machines Corporation | Method and system for storing structured documents in their native format in a database |
| US7519574B2 (en) * | 2003-08-25 | 2009-04-14 | International Business Machines Corporation | Associating information related to components in structured documents stored in their native format in a database |
| US8250093B2 (en) | 2003-08-25 | 2012-08-21 | International Business Machines Corporation | Method and system for utilizing a cache for path-level access control to structured documents stored in a database |
| US8775468B2 (en) | 2003-08-29 | 2014-07-08 | International Business Machines Corporation | Method and system for providing path-level access control for structured documents stored in a database |
| US7792880B2 (en) * | 2004-01-05 | 2010-09-07 | International Business Machines Corporation | Method and apparatus for efficient implementation of discontiguous objects |
| US7587566B2 (en) * | 2004-02-20 | 2009-09-08 | Microsoft Corporation | Realtime memory management via locking realtime threads and related data structures |
| US7546588B2 (en) * | 2004-09-09 | 2009-06-09 | International Business Machines Corporation | Self-optimizable code with code path selection and efficient memory allocation |
| US7398369B2 (en) * | 2004-10-28 | 2008-07-08 | International Business Machines Corporation | Memory leakage management |
| US20060173877A1 (en) * | 2005-01-10 | 2006-08-03 | Piotr Findeisen | Automated alerts for resource retention problems |
| US8171169B2 (en) | 2005-03-14 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for updating a graphical display in a distributed processing environment |
| US8423673B2 (en) | 2005-03-14 | 2013-04-16 | Citrix Systems, Inc. | Method and apparatus for updating a graphical display in a distributed processing environment using compression |
| US7412466B1 (en) * | 2005-05-31 | 2008-08-12 | Sun Microsystems, Inc. | Offset-based forward address calculation in a sliding-compaction garbage collector |
| US7809918B1 (en) * | 2005-07-22 | 2010-10-05 | American Megatrends, Inc. | Method, apparatus, and computer-readable medium for providing physical memory management functions |
| US7421453B2 (en) * | 2005-08-16 | 2008-09-02 | International Business Machines Corporation | Asynchronous linked data structure traversal |
| US7765528B2 (en) * | 2005-09-21 | 2010-07-27 | Hewlett-Packard Development Company, L.P. | Identifying sources of memory retention |
| US7890541B2 (en) * | 2006-02-17 | 2011-02-15 | International Business Machines Corporation | Partition by growth table space |
| FR2906380B1 (en) * | 2006-09-27 | 2008-12-19 | Trusted Logic Sa | SYSTEM AND METHOD FOR SECURING DATA. |
| US20080148002A1 (en) * | 2006-12-13 | 2008-06-19 | Fleming Matthew D | Method and Apparatus for Allocating A Dynamic Data Structure |
| US8037477B2 (en) * | 2007-01-23 | 2011-10-11 | Hewlett-Packard Development Company, L.P. | Efficient detection of sources of increasing memory consumption |
| US20080288725A1 (en) * | 2007-05-14 | 2008-11-20 | Moyer William C | Method and apparatus for cache transactions in a data processing system |
| US20090199126A1 (en) * | 2008-02-06 | 2009-08-06 | International Business Machines Corporation | Method for automatically organizing toolbars for a software application |
| US8095766B2 (en) * | 2008-04-07 | 2012-01-10 | International Business Machines Corporation | Method and system for approximating object sizes in an object-oriented system |
| US8082415B2 (en) | 2008-07-01 | 2011-12-20 | International Business Machines Corporation | Estimating the size of an in-memory cache |
| US8301672B2 (en) * | 2008-09-22 | 2012-10-30 | Advanced Micro Devices, Inc. | GPU assisted garbage collection |
| KR20100091853A (en) * | 2009-02-11 | 2010-08-19 | 삼성전자주식회사 | Embedded system conducting a dynamic memory management and memory management method thereof |
| US8347055B2 (en) * | 2009-06-30 | 2013-01-01 | Incard S.A. | Method to defrag a memory of an IC card |
| US8473900B2 (en) * | 2009-07-01 | 2013-06-25 | Advanced Micro Devices, Inc. | Combining classes referenced by immutable classes into a single synthetic class |
| JP4987997B2 (en) * | 2010-02-26 | 2012-08-01 | 株式会社東芝 | Memory system |
| US8327109B2 (en) * | 2010-03-02 | 2012-12-04 | Advanced Micro Devices, Inc. | GPU support for garbage collection |
| US8225065B2 (en) * | 2010-06-03 | 2012-07-17 | Microsoft Corporation | Hierarchical scalable memory allocator |
| US9218135B2 (en) | 2010-06-16 | 2015-12-22 | Microsoft Technology Licensing, Llc | Hierarchical allocation for file system storage device |
| US8527544B1 (en) | 2011-08-11 | 2013-09-03 | Pure Storage Inc. | Garbage collection in a storage system |
| US9329988B2 (en) * | 2011-08-19 | 2016-05-03 | Nvidia Corporation | Parallel dynamic memory allocation using a nested hierarchical heap |
| FR3034540A1 (en) * | 2015-04-03 | 2016-10-07 | Nexedi | METHOD FOR ANALYZING VERY LARGE VOLUMES OF DATA |
| EP3109764B1 (en) | 2015-06-23 | 2018-03-14 | Zaklady Urzadzen Komputerowych "ELZAB" S.A. | Flash file system |
| US10162552B2 (en) * | 2016-03-31 | 2018-12-25 | EMC IP Holding Company LLC | System and method for quasi-compacting garbage collection |
| US10168911B1 (en) * | 2017-06-13 | 2019-01-01 | Sap Se | Defragmentation of persistent main memory |
| US11010070B2 (en) * | 2019-01-31 | 2021-05-18 | Ralph Crittenden Moore | Methods for aligned, MPU region, and very small heap block allocations |
| US11314428B1 (en) * | 2020-10-09 | 2022-04-26 | Western Digital Technologies, Inc. | Storage system and method for detecting and utilizing wasted space using a file system |
| US11580013B2 (en) | 2020-10-30 | 2023-02-14 | Nutanix, Inc. | Free space management in a block store |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4989137A (en) * | 1984-07-12 | 1991-01-29 | Texas Instruments Incorporated | Computer memory system |
| US4775932A (en) * | 1984-07-31 | 1988-10-04 | Texas Instruments Incorporated | Computer memory system with parallel garbage collection independent from an associated user processor |
| US4989134A (en) * | 1987-03-20 | 1991-01-29 | Hewlett-Packard Company | Method and apparatus for enhancing data storage efficiency |
| US4907151A (en) * | 1988-09-30 | 1990-03-06 | Digital Equipment Corporation | System and method for garbage collection with ambiguous roots |
| US5321834A (en) * | 1989-11-28 | 1994-06-14 | Xerox Corporation | Method and system for reclaiming unreferenced computer memory space |
| US5218698A (en) * | 1991-11-22 | 1993-06-08 | Aerojet-General Corporation | Garbage collection system for a symbolic digital processor |
-
1993
- 1993-07-26 CA CA002119788A patent/CA2119788C/en not_active Expired - Lifetime
- 1993-07-26 DE DE69327089T patent/DE69327089T2/en not_active Expired - Lifetime
- 1993-07-26 JP JP6504753A patent/JPH06511582A/en active Pending
- 1993-07-26 WO PCT/US1993/007021 patent/WO1994002898A1/en active IP Right Grant
- 1993-07-26 EP EP93918396A patent/EP0606461B1/en not_active Expired - Lifetime
-
1994
- 1994-08-24 US US08/372,131 patent/US5561786A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69327089T2 (en) | 2000-04-13 |
| EP0606461A1 (en) | 1994-07-20 |
| JPH06511582A (en) | 1994-12-22 |
| US5561786A (en) | 1996-10-01 |
| DE69327089D1 (en) | 1999-12-30 |
| EP0606461B1 (en) | 1999-11-24 |
| WO1994002898A1 (en) | 1994-02-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2119788C (en) | Computer method and system for allocating and freeing memory | |
| JP3628032B2 (en) | Computer system and method for conservative stack and generational heap garbage collection | |
| US5664179A (en) | Modified skip list database structure and method for access | |
| US5109336A (en) | Unified working storage management | |
| US6029170A (en) | Hybrid tree array data structure and method | |
| US6301616B1 (en) | Pledge-based resource allocation system | |
| DE69732755T2 (en) | Intermediate level for navigation system | |
| JP3183901B2 (en) | Memory management method | |
| EP0632364B1 (en) | Efficient storage of object in a file system | |
| KR100541174B1 (en) | Data processor with localised memory reclamation | |
| JP3844370B2 (en) | Computer method and storage structure for storing and accessing multidimensional data | |
| US5548751A (en) | Dynamic data storage system allowing variable size records and fields by using linked record segments | |
| US6438562B1 (en) | Parallel index maintenance | |
| US6865585B1 (en) | Method and system for multiprocessor garbage collection | |
| US6658437B1 (en) | System and method for data space allocation using optimized bit representation | |
| US6928460B2 (en) | Method and apparatus for performing generational garbage collection in a segmented heap | |
| US6105040A (en) | Method and apparatus for managing stored objects | |
| EP0557736A2 (en) | A method and system for file system management using a flash-erasable, programmable, read-only memory | |
| JP2002540502A (en) | Method and apparatus for pointer relocation optimization of virtual memory mapping and transaction management in a database system | |
| US20060235910A1 (en) | Apparatus and method for a managing file system | |
| US20050138092A1 (en) | Relative positioning and access of memory objects | |
| US7499961B2 (en) | Method and apparatus for limiting the size and facilitating maintenance of remembered sets in a space incremental garbage collector | |
| KR100622114B1 (en) | A method for efficiently managing a dynamic memory in embedded system and a system therefor | |
| US6205440B1 (en) | Method of providing information from query results stored as source code files | |
| US6961739B2 (en) | Method for managing directories of large-scale file system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |