We consider the problem of supporting compacting garbage collection in the presence of modern compiler optimizations. Since our collector may move any heap object, it must accurately locate, follow, and update all pointers and values derived from pointers. To assist the collector, we extend the compiler to emit tables describing live pointers, and values derived from pointers, at each program location where collection may occur. Significant results include identification of a number of problems posed by optimizations, solutions to those problems, a working compiler, and experimental data concerning table sizes, table compression, and time overhead of decoding tables during collection. While gc support can affect the code produced, our sample programs show no significant changes, the table sizes are a modest fraction of the size of the optimized code, and stack tracing is a small fraction of total gc time. Since the compiler enhancements are also modest, we conclude that the approach is...

Abstract not found

this paper, we explore an important issue that a stack tracing scheme for a statically typed language needs to address: derived locations. A memory slot or a register is called a derived location if its value is determined by arithmetic from the base addresses of one or more objects or from other derived locations. The objects involved in the derivation are referred to as the involved objects of the derived location. Derived locations are important for two reasons. First, the involved objects of a reachable derived location should be saved during a scavenge. Second, when an involved object is moved during a scavenge, the derived locations dependent on it should be updated as well

this memory allocator to be the only one in the program; it can satisfy the dynamic memory needs of the standard libraries by treating their allocation calls as requests for foreign objects. Foreign objects are not examined by the collector; they should only reference collected objects through smart pointers, not through raw pointers. The C++ feature that makes this process convenient is overloadable dynamic storage allocation operators: new and delete. These operators permit every class to supply functions 67 #include "gc.h" #pragma GCON CL class CL -- CL * ptr1; OTHER * ptr2; static void finalize(CL *); /* optional */ ... ; Figure 5.3: A class with internal pointers to handle memory allocation and deletion. In this case, operator new for a managed class passes in the type tag to the memory allocator. The default, global operator new passes in the type tag for foreign objects. A call to malloc(), which circumvents new, also allocates a foreign object. There are two main changes for a program that uses the precompiler for GC. Firstly, pragmas are used to indicate three things: 1. which application classes are collected, 2. which collector applies to which classes, and, 3. that the standard library classes are not collected. Secondly, global and foreign pointers are defined to be smart pointers rather than raw pointers. In conjunction with the copying collector, it may additionally be desirable to define certain stack pointers to be smart pointers; this can reduce the number of pointers that are found conservatively, thereby allowing more objects to be copied and compacted. Figure 5.3 shows some sample input to the precompiler; the transformations for locating internal pointers are shown in Fig. 5.4. These transformations are performed either by the precompiler or by t...

This report is a shorter version of UCSC--CRL--93--26. Extensive source code in appendices is omitted from this version. Keywords: Garbage collection, memory management, object-oriented programming, C++, memory allocation, reference counting i

Hardware-assisted garbage collection combines the potential of high average-case allocation rates and memory bandwidth with fast worst-case allocation, fetch, and store times. This paper describes an architecture that allows memory fetch and store operations to execute, on the average, nearly as fast as traditional memory.Itdescribes a feasible implementation of a garbage-collected memory module, but does not provide a thorough discussion of possible design alternatives, nor does it provide rigorous justification for choices between available design alternatives. 17 November 1992 Department of Computer Science Iowa State University 226 AtanasoffHall Ames, Iowa 50011-1040 *This work was supported by the National Science Foundation under Grant MIP-9010412, and by a National Science Foundation Graduate Fellowship. Preferred Embodiment of a HardwareAssisted Garbage-Collection System * Kelvin D. Nilsen William J.Schmidt Department of Computer Science Iowa State University...

Nondeferred reference-counting (RC) garbage collection is among the oldest memory-management methods. Despite offering unique advantages, little attention has been paid on how to correctly implement it for modern programming languages. This paper revisits this collection method and describes how to implement it for a modern object-oriented language in an optimizing compiler. The main contribution is a general algorithm that realizes one form of nondeferred RC collection for an object-oriented language having features such as exceptions, interior pointers, and object pinning. The algorithm abstracts the pertinent characteristics of instructions using concepts from data-flow analysis, such as def/use information, so that instructions are handled in a uniform manner, instead of in an ad hoc or special-case way. The abstracted information is used to systematically compute what increments and decrements to do, even in the presence of subtle conditions such as exceptional control flow. These techniques enabled us to compile a large suite of programs to use nondeferred RC collection. The paper also discusses the modifications that were necessary in the compiler for supporting the inserted RC operations, and reports measurements from a reference implementation.