Memory management is a critical issue for many large object-oriented applications, but in C++ only explicit memory reclamation through the delete operator is generally available. We analyse different possibilities for memory management in C++ and present a dynamic memory management framework which can be customised to the need of specific applications. The framework allows full integration and coexistence of different memory management techniques. The Customisable Memory Management (CMM) is based on a primary collector which exploits an evolution of Bartlett's mostly copying garbage collector. Specialised collectors can be built for separate memory heaps. A Heap class encapsulates the allocation strategy for each heap. We show how to emulate different garbage collection styles or user-specific memory management techniques. The CMM is implemented in C++ without any special support in the language or the compiler. The techniques used in the CMM are general enough to be applicable also to...

. Automatic garbage collection relieves programmers from the burden of managing memory themselves and several techniques have been developed that make garbage collection feasible in many situations, including real time applications or within traditional programming languages. However optimal performance cannot always be achieved by a uniform general purpose solution. Sometimes an algorithm exhibits a predictable pattern of memory usage that could be better handled specifically, delaying as much as possible the intervention of the general purpose collector. This leads to the requirement for algorithm specific customisation of the collector strategies. We present a dynamic memory management framework which can be customised to the needs of an algorithm, while preserving the convenience of automatic collection in the normal case. The Customisable Memory Management (CMM) organizes memory in multiple heaps. Each heap is defined as a C++ class which encapsulates a particular storage discipli...

this memory can be freed at the end of this step. The only data to be preserved is the simplified polynomial which must be inserted into the final basis. 2 In many cases simplify returns a zero polynomial. In these cases no memory must be preserved. 3 Since the complexity of the algorithm is exponential, the amount of memory allocated by simplify also grows exponentially with the size of the ideal. We can tune the memory management for this algorithm by means of the CMM, adopting two different heaps: the default one (CmmHeap::heap) and a special one for this algorithm (tempHeap), an instance of the HeapStack class sketched below. 12 G. Attardi and T. Flagella Memory is usually allocated inside the default heap, but before calling simplify the heap is switched to the tempHeap. All the memory allocated during simplify is therefore obtained from the tempHeap heap. Notice that this does not require any changes to any of the remaining functions in the PoSSo library: the algebraic operations on polynomials, coefficients etc. are unmodified and use the standard new operator to allocate objects. After returning from simplify we switch back to the default heap, and the polynomial returned by simplify is copied into the default heap. At this point the tempHeap contains no live data and can be freed with a single operation without involving a garbage collection. Here again is the code augmented with instructions for CMM memory management. CmmHeap *previousHeap = CmmHeap::heap; // Save the current heap

We propose adding safe, efficient garbage collection to C++, eliminating the possibility of storage-management bugs and making the design of complex, object-oriented systems much easier. This can be accomplished with almost no change to the language itself and only small changes to existing implementations, while retaining compatibility with existing class libraries. Our proposal is the first to take a holistic, system-level approach, integrating four technologies. The language interface specifies how programmers access garbage collection through the language. An optional safe subset of the language automatically enforces the safe-use rules of garbage collection and precludes storage bugs. A variety of collection algorithms are compatible with the language interface, but some are easier to implement and more compatible with existing C++ and C implementations. Finally, codegenerator safety ensures that compilers generate correct code for use with collectors. John R. Ellis and David L. D...