Memory management in runtime environments is often devised so as to provide convenience for the software engineer. For this reason, runtime environments such as Java (Java is a Registered Trademark of Sun Microsystems Inc.) include heap memory having a garbage collector. A garbage collector is a runtime facility for automatically identifying and discarding inactive data from memory, such as objects, in order to free-up storage. Garbage collection is a luxury afforded by the efficiencies of modern computer systems that serves to liberate software engineers from the task of programmatically discarding each and every inactive object.
Modern garbage collection algorithms make use of the weak generational hypothesis that most allocated objects will be “short lived” (i.e. objects will be discardable a relatively short time after they are created). To make use of this hypothesis, the objects are allocated in a section of a memory heap called a “nursery”. The nursery is garbage collected much more frequently than the main heap where older (tenured) objects are stored and typically consists of two areas known as the allocate space and the survivor space. As the objects are copied into contiguous memory the nursery is automatically compacted. A Copying garbage collection algorithm copies live objects from the nursery allocation space into a survivor memory performing compaction at the same time. survivor memory is a portion of the nursery heap of configurable size. For example, the survivor memory may constitute up to 50% of the total memory allocated to the nursery.
FIG. 1a is a schematic diagram of software applications 202 in execution in a computer system. Each of the software applications has associated heap memory 206 supplied by a memory manager 204. The heap memory 206 occupies an address range that can be a physical address range or a logical address range into which physical memory is mapped by the memory manager 204. For example, the heap memory 206 is a nursery heap as part of a larger application heap. The memory manager 204 is operable to supply units of memory of the computer system to software applications 202. For example, the memory manager 204 is a component of an operating system in the computer system, such as a kernel memory manager.
A part 208 of the heap 206 is a dedicated survivor memory for use during a garbage collection process. The survivor memory part 208 is characterised in that it is not available for the allocation of objects by the application 202 and it is reserved for use during a garbage collection process. FIG. 1b is a schematic diagram of the heap 206 of a software application 202 of FIG. 1a. In execution the software application 202 stores and retrieves data in the heap 206. The heap 206 includes allocated parts (hatched and shaded) corresponding to stored data. Such data can include, for example, allocated software objects, data structures, records, fields or variables. A garbage collection algorithm is operable to periodically process the heap 206 to discard unused data items allocated in the heap 206. Such an algorithm includes a Copying garbage collection algorithm. In processing the heap 206, the garbage collection algorithm identifies data items in the heap 206 that are active. An active data item is a data item that is in use by the software application 202. In contrast, a data item that is not active is no longer required by the software application 202. For example, an active data item is referenced by the software application 202, such as by a memory pointer or object reference. The garbage collection algorithm copies such identified active data items to the survivor memory 208. The garbage collection algorithm can copy the identified active data items to contiguous locations in the survivor memory 208 in order to compact the data items. Subsequently, only data items recorded in the survivor memory 208 need be retained (hence “survivor”) and all other data items in the heap 206 (corresponding to data items that are not active) can be discarded.
One problem with such Copying garbage collectors is that each application maintains its own survivor memory even if it is not currently performing a garbage collection. This problem is particularly acute in systems having a large number of software applications in execution and a correspondingly large amount of memory allocated as survivor memory. Also, since survivor memory is reserved for use during the garbage collection process, it is not available for the storage of data by the software applications 202.
It would therefore be advantageous to provide for the benefits of garbage collection with survivor memory for copying garbage collectors without a need to dedicate heap memory as survivor memory for each software application in execution.
USPTO Backgrounds
USPTO Backgrounds