Abstract: A novel linked-list-based concurrent shared object implementation has been developed that provides non-blocking and linearizable access to the concurrent shared object. In an application of the underlying techniques to a deque, non-blocking completion of access operations is achieved without restricting concurrency in accessing the deque's two ends. In various realizations in accordance with the present invention, the set of values that may be pushed onto a shared object is not constrained by use of distinguishing values. In addition, an explicit reclamation embodiment facilitates use in environments or applications where automatic reclamation of storage is unavailable or impractical.

Abstract: A multiprocessor, multi-program, stop-the-world garbage collection program is described. The system initially over partitions the root sources, and then iteratively employs static and dynamic work balancing. Garbage collection threads compete dynamically for the initial partitions. Work stealing double-ended queues, where contention is reduced, are described to provide dynamic load balancing among the threads. Contention is resolved by using atomic instructions. The heap is broken into a young and an old generation where parallel semi-space copying is used to collect the young generation and parallel mark-compacting the old generation. Speed and efficiency of collection is enhanced by use of card tables and linking objects, and overflow conditions are efficiently handled by linking using class pointers. A garbage collection termination employs a global status word.

Abstract: A computer system (10) implements a memory allocator that employs a data structure (FIG. 3) to maintain an inventory of dynamically allocated memory available to receive new data. It receives from one or more programs requests that it allocate memory from a dynamically allocable memory “heap.” It responds to such requests by performing the requested allocation and removing the thus-allocated memory block from the inventory. Conversely, it adds to the inventory memory blocks that the supported program or programs request be freed. In the process, it monitors the frequencies with which memory blocks of various sizes are allocated, and it projects from those frequencies future demand for memory blocks of those sizes. To split a relatively large block in order to meet an actual or expected request for a smaller block, it bases its selection of the larger block to be split on whether the supply of free blocks of the larger block's size is great enough to meet the expected demand for such blocks.

Abstract: A garbage collector treats a dynamically allocated heap as divided into a young generation and an old generation, to which it applies different collection policies. To keep track of where a mutator has made reference modifications in the old generation between collection intervals, the collector divides the old generation into “cards” and maintains a “card table” that contains an entry for each card. Initially, each entry's value is clean, and, when the collector scans the old generation for references to young-generation objects, it skips cards whose entries are clean. When the mutator modifies a reference in a card, it gives the card's card-table entry a dirty value. If a thread scanning a card during a given collection interval finds that no references to young-generation objects that remain in the young generation through the end of that collection interval, it sets the card's card-table entry to a clean value.

Abstract: A garbage collector operates in multiple threads, and one thread can be parsing a region containing a free block while another thread is allocating space from that free block for an object being relocated to that region. The object being relocated may be an array object, for which the length determination is based on more than one word in the object; it may be based on a class-identifying word and a number-of-elements word. To prevent a parsing thread from parsing erroneously by reading both of those words between the relocating thread's writing one of them and writing the other, the relocating thread first writes into the classifying word a distinguished value from which a parsing thread can conclude that the values its reads in other fields of the block are not to be trusted.

Abstract: A garbage collector maintains a block-offset table. That table contains locator information including an entry for each of a plurality of “cards” into which the collector treats at least a portion of heap memory as divided. Certain of the code values that an entry can assume specify the location of the object or free block in which the card begins. Other codes indicate that such information can be obtained from a table entry some number of table entries ahead of the entry that assumes that value. The possible offset values in the encoding populate only very sparsely the range between the highest and lowest values represented by the possible code values. By thus leaving large gaps in the range of possible offsets encoded, a collector can achieve an advantageous compromise between the expense of finding a block location and the expense of updating the block-offset table.

Abstract: A garbage collector divides the garbage-collected heap into “cards.” It maintains a table containing a card-object table entry for each card. A card's entry contains information from which the collector can determine where any references in the card are located and thereby identify objects that may be reachable. The encoding of a card's table entry is not restricted to values that indicate the location of the object in which the card begins. Instead, its possible values additionally include ones that indicate that the card begins with a certain number of references or that an object begins at a given location in the middle of the card. The collector thereby avoids consulting object's class information unnecessarily.

Abstract: A compiler produces mutator code to be run with a generational garbage collector. The mutator initially allocates objects in a “young-generation” part of a garbage-collected heap and then promotes some of them to an “old-generation” part of the heap if they have remained reachable for some time. In some cases, a criterion on which its decision to promote a given object is based is whether a mutator's execution has passed a mutator-code segment that is associated with and follows the point in the code that called for the object's dynamic allocation. The compiler output designates certain of the mutator's dynamic-allocation instructions as being ones whose resultant allocated objects will be considered “pinned.” The compiler associates with such allocation instructions respective segments of the code following the instructions. In those code segments, respective initially allocated objects are considered to remain pinned.

Abstract: A computer system (10) implements a memory allocator that employs a data structure (FIG. 3) to maintain an inventory of dynamically allocated memory available to receive new data. It receives from one or more programs requests that it allocate memory from a dynamically allocable memory “heap.” It responds to such requests by performing the requested allocation and removing the thus-allocated memory block from the inventory. Conversely, it adds to the inventory memory blocks that the supported program or programs request be freed. In the process, it monitors the frequencies with which memory blocks of various sizes are allocated, and it projects from those frequencies future demand for memory blocks of those sizes. To split a relatively large block in order to meet an actual or expected request for a smaller block, it bases its selection of the larger block to be split on whether the supply of free blocks of the larger block's size is great enough to meet the expected demand for such blocks.

Abstract: A computer system (10) implements a memory allocator that employs a data structure (FIG. 3) to maintain an inventory of dynamically allocated memory available to receive new data. It receives from one or more programs requests that it allocate memory from a dynamically allocable memory “heap.” It responds to such requests by performing the requested allocation and removing the thus-allocated memory block from the inventory. Conversely, it adds to the inventory memory blocks that the supported program or programs request be freed. In the process, it monitors the frequencies with which memory blocks of different sizes are allocated, and it projects from those frequencies future demand for different-sized memory blocks. When it needs to coalesce multiple smaller blocks to fulfil an actual or expected request for a larger block, it bases its selection of which constituent blocks to coalesce on whether enough free blocks of a constituent block's size exist to meet the projected demand for them.

Abstract: A computer system (10) implements a memory allocator that employs a data structure (FIG. 3) to maintain an inventory of dynamically allocated memory available to receive new data. It receives from one or more programs requests that it allocate memory from a dynamically allocable memory “heap.” It responds to such requests by performing the requested allocation and removing the thus-allocated memory block from the inventory. Conversely, it adds to the inventory memory blocks that the supported program or programs request be freed. In the process, it monitors the frequencies with which memory blocks of various sizes are allocated, and it projects from those frequencies future-demand values for memory blocks of those sizes. It then splits larger blocks into smaller ones preemptively, i.e., before a request for the result of the splitting.

Abstract: A computer system (10) implements a memory allocator that employs a data structure (FIG. 3) to maintain an inventory of dynamically allocated memory available to receive new data. It receives from one or more programs requests that it allocate memory from a dynamically allocable memory “heap.” It responds to such requests by performing the requested allocation and removing the thus-allocated memory block from the inventory. Conversely, it adds to the inventory memory blocks that the supported program or programs request be freed. In the process, it monitors the frequencies with which memory blocks of various sizes are allocated, and it projects from those frequencies future-demand values for memory blocks of those sizes. It then splits larger blocks into smaller ones preemptively, i.e., before a request for the result of the splitting.

Abstract: A multiprocessor, multi-program, stop-the-world garbage collection program is described. The system initially over partitions the root sources, and then iteratively employs static and dynamic work balancing. Garbage collection threads compete dynamically for the initial partitions. Work stealing double-ended queues, where contention is reduced, are described to provide dynamic load balancing among the threads. Contention is resolved by using atomic instructions. The heap is broken into a young and an old generation where parallel semi-space copying is used to collect the young generation and parallel mark-compacting the old generation. The old generation heap is divided into a number of contiguous cards that are partitioned into subsets. The cards are arranged into the subsets so that non-contiguous cards are contained in each subset. Speed and efficiency of collection is enhanced by use of card tables and linking objects, and overflow conditions are efficiently handled by linking using class pointers.

Abstract: A novel linked-list-based concurrent shared object implementation has been developed that provides non-blocking and linearizable access to the concurrent shared object. In an application of the underlying techniques to a deque, non-blocking completion of access operations is achieved without restricting concurrency in accessing the deque's two ends. In various realizations in accordance with the present invention, the set of values that may be pushed onto a shared object is not constrained by use of distinguishing values. In addition, an explicit reclamation embodiment facilitates use in environments or applications where automatic reclamation of storage is unavailable or impractical.

Abstract: The Hat Trick deque requires only a single DCAS for most pushes and pops. The left and right ends do not interfere with each other until there is one or fewer items in the queue, and then a DCAS adjudicates between competing pops. By choosing a granularity greater than a single node, the user can amortize the costs of adding additional storage over multiple push (and pop) operations that employ the added storage. A suitable removal strategy can provide similar amortization advantages. The technique of leaving spare nodes linked in the structure allows an indefinite number of pushes and pops at a given deque end to proceed without the need to invoke memory allocation or reclamation so long as the difference between the number of pushes and the number of pops remains within given bounds. Both garbage collection dependent and explicit reclamation implementations are described.

Abstract: An object structure's header (40) allocates a two-bit synchronization-state field (42) solely to monitor data for implementing synchronization on that object. When the object is locked by a particular execution thread, or when one or more execution threads are waiting for a lock or notification on that object, its header contains a pointer to monitor resources in the form of a linked list of lock records (50, 52, 54) associated with the threads involved. The synchronization-state field (42) ordinarily contains an indication of whether such a linked list exists and, if so, whether its first member is associated with a thread that has a lock on the object. When a thread attempts to gain access to that linked list, it employs an atomic swap operation to place a special busy value in that lock-state field (42) and write its execution-environment pointer into the object's header (40).

Abstract: Methods, systems, and articles of manufacture consistent with the present invention provide a program component including a set of instructions native to the system, include in the set of native instructions an instruction to maintain information on use of a particular object, and permit reuse of memory resources corresponding to the particular object based on an indication from a source that the particular object is no longer being used, the source being different from any source used to provide information on use of objects associated with non-native instructions of the program component. Additionally, garbage collection is not permitted during native code operations to read or write data in object fields because during such operations an indication exists that such collection may be inaccurate and could possibly reclaim or relocate objects referenced by native code though not specified as such in the native code stack and global variables.

Abstract: A system for mostly concurrent compaction in a garbage collection system is disclosed. Objects that have been allocated to a program are relocated by first identifying those variables pointing to a selected set of objects that are in use within a subset of memory. As these pointers are identified, they are added to a data structure. The selection of the objects, identification of the pointers, and addition of the pointers to the data structure may all be performed concurrently with execution of the program. At the same time, a write barrier marks as “dirty” those memory regions in which one or more pointers are modified by the program. A number of locations outside the subset of memory are reserved to be used to store the selected objects. Execution of the program is then suspended. The memory regions marked as “dirty” are examined to identify any further variables pointing to the selected objects. Any such identified variables are added to the data structure.

Abstract: A dynamic compiler determines whether to inline methods in place of virtual method calls by inspecting such calls' receiver expressions. If a given call site meets other criteria for inlining, the method is inlined if its receiver expression can be proved to have a property called “pre-existence.” One kind of expression whose pre-existence is easily proved is a calling-procedure argument to which the body of the calling procedure makes no assignment. One of the other criteria is that the argument's static type is a class whose definition of the callee method has not been overridden, and the compiler employs a dependency data structure to record against both the caller and the callee that the caller contains code whose validity depends on the assumption that this criterion has been met.

Abstract: In accordance with the present invention a method for modifying a sequence of instructions to improve memory management within a storage device during execution of the instructions, comprises the steps, performed by a processor, of (a) analyzing the sequence of instructions for a conflict indicating an undeterminable variable type, (b) determining the type of conflict, and (c) modifying the sequence of instructions to eliminate the conflict based on the determination.