Stack Tracing In A Statically Typed Language

Transcription

1 Stack Tracing In A Statically Typed Language Amer Diwan Object Oriented Systems Laboratory Department of Computer Science University of Massachusetts October 2, Introduction Statically-typed languages such as Modula-3 [Cardelli et al., 1989] provide many opportunities for compile-time garbage collection support. Compiler generated tables can assist the collector in locating the root pointers and in updating them when objects are moved. This obviates the need for run-time tags in the stack and offers substantial performance improvements. In 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 1. In the remainder of this paper we describe the key issues that arise when we add compiler support to assist the garbage collector in finding and updating derived locations. We also describe our solutions for Modula-3. Although our work has been done in the context of Modula-3, it is relevant to other languages and collectors as well. In Section 6 we talk about similar issues that have come up in work on a C system using an ambiguous roots collector. 2 Creation of Derived Locations In this section we identify some language features and compiler optimizations that produce derived locations and give an example derivation in each case. By convention, all arrays, unless otherwise specified, are one dimensional integer arrays with base index 0. Also, we adopt the convention of presenting all source code in Modula-3 syntax and all compiler/optimizer output in C syntax. This work is part of the author s M.S. project. 1 An object may be an involved object for any number of derived locations. 1

2 Pass by Reference: A pointer to the middle of array A is created when A[i] is passed by VAR in a procedure call 2. Note that passing a derived location by VAR to a routine creates a new derived location. Strength Reduction: The body A[i] := 13; INC (i); of an array initialization loop can be turned into *p++ = 13, with p appropriately initialized. Virtual Array Origin: If A is an array of type ARRAY [7..13] OF INTEGER, the obvious method of accessing A[i] is *(&A[0] + (i - 7) * sizeof (int)). The subtraction can be avoided by treating the array as if it were of type ARRAY [0..13] OF INTEGER. Note that in this optimization, the derived location can point outside its involved object. Common Subexpression Elimination: The code A[i,j] := 10; A[i,k] := 20; may be compiled into t = &A[i]; *(t + j * sizeof (int)) = 10; *(t + k * sizeof (int)) = 20; if the optimizer can determine that t is being computed twice and that i is not updated. Double Indexing: If A[i] := 10; B[i] := 20; is naively compiled, it may yield *(&A[0] + (i * sizeof(int))) = 10; *(&B[0] + (i * sizeof(int))) = 20; This may be optimized to t1 = &B[0] - &A[0]; t2 = &A[0] + (i * sizeof(int)); *t2 = 10; *(t2 + t1) = 20; Note that this time the derived location t1 is not even of pointer type. 3 Using the Compiler Generated Tables The base tables associate each derived location with its base pointers (see Figure 1) at a given program point 3. These tables are used by the scavenger during garbage collection to keep derived locations consistent with their base pointers. 2 This is the only way of creating a derived location from within a Modula-3 program. Unrestricted pointer arithmetic is allowed in unsafe modules, but the validity of the addresses produced by these operations is implementation dependent [Cardelli et al., 1989]. 3 As it would probably be prohibitively expensive to have this information available for each program point, we store this information for some carefully chosen points in the program. 2

3 a Base Relation Base Value b1 b2 b3 + + Figure 1: Base table for a at program point p The Relation column in the table indicates how the corresponding base pointer is related to the derived location (either added or subtracted 4 ). For instance, in Figure 1, b1 and b3 are added in the derivation of a, whereas b2 is subtracted. This is equivalent to saying that the reaching definition of a at program point p is: a := b1 - b2 + b3 + <expression that does not involve any pointers> The Base Value column is used by the collector at run time. At the beginning of a scavenge, the collector goes through the base tables of each live derived location, and fills in the current value of the base pointers in the Base Value column. At the end of a scavenge, the collector goes through these tables again, this time computing the difference between the current value of a base pointer and its saved value, and uses the difference to update the derived location. If a base is a derived location then its value needs to be updated before any locations that are derived from it. Fortunately, this ordering can be accomplished if the derived locations are updated while traversing the stack from the bottom up; if X is a derived location and its base pointer Y is also a derived location then Y must be lower in the stack than X. Note that we assume the relations are easily invertible which is true in our case since we allow only addition and subtraction. If we allow other operators we will need to augment the scheme to recalculate the entire deriving expression. 4 Some Complications The job of the compiler would be simple if it could correctly, statically, and unambiguously identify the base pointers 5 for each derived location at any given point in the program. Unfortunately, this is not the case for at least two scenarios: when multiple derivations reach a program point, and when a base pointer dies before the derived location. Following are examples of each of these scenarios. 4 Our current implementation supports derived location creation only through pointer addition and subtraction. If other operators are needed (like bit-manipulation operators), we can work them into our scheme with little effort. 5 The pointer(s) used in the derivation of a derived location. 3

4 SOURCE OPTIMIZED i := 1; WHILE (cond) IF (inv) THEN PRINT (P[i]); ELSE PRINT (Q[i]); INC (i); =) i = 1; if (inv) t = &P[0] + 1; else t = &Q[0] + 1; while (cond) PRINT (*(t + i++)); If inv is invariant, the optimizer may hoist the conditional out of the loop causing t s derivation to be ambiguous inside the loop; t is derived from either &P[0] or &Q[0]. SOURCE OPTIMIZED A: REF ARRAY [1..10] OF INTEGER; FOR i := 1 TO LAST (Aˆ) DO s := s + Aˆ[i]; =) for (i = 1; i <= 10; i++) s = s + *A++; If data flow analysis can determine that A is dead after the loop, then the compiler may generate the code on the right. In this code, A s base pointer (the original value of A) is not available to the collector inside the loop. 5 Solutions It should be clear that determining the base pointers of t in the ambiguous derivation scenario in Section 4 cannot be accomplished at compile time; some run-time overhead is unavoidable. Our solution adds one additional assignment to each path of an ambiguous derivation. The idea is to have a path variable; its value determines which of the various paths were taken, and hence which base table to use. i = 1; if (inv) f t 0 = <Expression indicating that this path was taken> t = &P[0] + 1; g else f t 0 = <Expression indicating that this path was taken> t = &Q[0] + 1; g while (cond) PRINT (*(t + i++)); 4

5 Now, rather than having a base table for t, we associate t with t 0. Based on the value of t 0, the garbage collector associates a base table with t. Note that a base table is created for each alternative derivation; the appropriate one is chosen at run time based on the value of t 0. The problem of dead base pointers is solved if we can convince the compiler that the base pointers of a derived location are live at every use of the derived location. We do this by making our compiler consider a use of a derived location as a use of each of its base pointers. This forces the compiler to retain the base pointers for the lifetime of the derived locations that are derived from them. 6 Related Work Boehm [Boehm, 1991b; Boehm, 1991a] is currently incorporating garbage collection support in a C compiler. They are using an ambiguous roots collector and therefore do not need to disambiguate derivations; since they never move objects, they do not need to update derived locations. However, they do need to ensure that any object reachable from a derived location is also reachable from a pointer to the base of the object. This problem is similar to our dead base pointer scenario described in Section 4. 7 Conclusions We have described how garbage collection schemes can benefit from the compile-time type information available for statically typed languages. We have also described problems that need to be dealt with effectively if the collector is to gain much benefit from compile-time information, along with our solutions to the problem. Our initial implementation for Modula-3 is almost complete. We expect to have some preliminary measurements (of base table sizes, etc) available soon. 8 Acknowledgments I would like to thank my advisor Eliot Moss for his guidance during this work. I also wish to thank Tony Hosking, Rick Hudson, Eliot Moss, and Darko Stefanovic for their comments on drafts of this paper. References [Boehm, 1991a] Hans-Juergen Boehm. Personal communication, July [Boehm, 1991b] Hans-Juergen Boehm. A Proposal for GC-safe C Compilation. Draft, June [Cardelli et al., 1989] Luca Cardelli, James Donahue, Lucille Glassman, Mick Jordan, Bill Kalsow, and Greg Nelson. Modula-3 report (revised). Tech. Rep. DEC SRC 52, DEC Systems Research Center/Olivetti Research Center, Palo Alto/Menlo Park, CA, Nov