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...

. Many high-level language compilers generate C code and then invoke a C compiler to do code generation, register allocation, stack management, and low-level optimization. To date, most of these compilers link the resulting code against a conservative mark-sweep garbage collector in order to reclaim unused memory. We introduce a new collector, MCC, based on mostly-copying collection, and characterize the conditions that favor such a collector over a mark-sweep collector. In particular we demonstrate that mostly-copying collection outperforms conservative mark-sweep under the same conditions that accurate copying collection outperforms accurate mark-sweep: Specifically, MCC meets or exceeds the performance of a mature mark-sweep collector when allocation rates are high, and physical memory is large relative to the live data. 1 High Level Overview Languages such as C [1] and C++ [27] are GC-unfriendly because they allow programs to violate the key premise of tracing garbage collection--...

Mark and sweep garbage collectors (GC) are classical but still very efficient automatic memory management systems. Although challenged by other kinds of systems, such as copying collectors, mark and sweep collectors remain among the best in terms of performance. This paper describes our implementation of an efficient mark and sweep garbage collector tailored to each program. Compiler support provides the type information required to statically and automatically generate this customized garbage collector. The segregation of objects by type allows the production of a more efficient GC code. This technique, implemented in SmallEiffel, our compiler for the object-oriented language Eiffel, is applicable to other languages and other garbage collection algorithms, be they distributed or not. We present the results obtained on programs featuring a variety of programming styles and compare our results to a well-know and high quality garbage collector.

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