US20020129343A1 - Estimation of object lifetime using static analysis - Google Patents
Estimation of object lifetime using static analysis Download PDFInfo
- Publication number
- US20020129343A1 US20020129343A1 US09/751,566 US75156600A US2002129343A1 US 20020129343 A1 US20020129343 A1 US 20020129343A1 US 75156600 A US75156600 A US 75156600A US 2002129343 A1 US2002129343 A1 US 2002129343A1
- Authority
- US
- United States
- Prior art keywords
- program
- graph
- point
- analysis
- objects
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
- G06F8/433—Dependency analysis; Data or control flow analysis
- G06F8/434—Pointers; Aliasing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
- G06F12/0276—Generational garbage collection
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
- Y10S707/99957—Garbage collection
Definitions
- This invention relates to computational methods. More particularly this invention relates to the static analysis of the lifetimes of heap-allocated objects in functioning computer programs and the application of this analysis to generational garbage collection of heap memory.
- the primary overhead for a copying generational garbage collection is the repeated copying of the object until it reaches the oldest generation.
- profiling of information has been proposed to estimate object lifetime. That estimation has then been used dynamically during the course of collection cycles to choose the proper generation in which to allocate the object.
- This scheme has been shown to indeed avoid the overhead associated with allocating a long-lived object in the youngest generation and then promoting it to an older generation. But this technique has significant drawbacks and incurs considerable runtime overhead.
- Profiling involves program instrumentation in order to train executions of a program, and further requires collecting and storing the results for later use. Such a process slows down the execution time, sometime by two order of magnitude, and is impractical for large programs. In addition, the results depends on the training input set.
- Data flow analysis computes information about the potential behavior of a program in terms of the definitions and uses of data objects. Such data flow information is important for optimizing compilers, program environments, and understanding tools. It can also be used in a software-testing system or to provide compiler and runtime support for the parallel execution of programs originally written in sequential languages.
- Aliasing occurs when there exists more than one access path to a storage location.
- An access path is constructed from variables, pointer dereference operators, and structure field selection operators. In C such an expression would include a variable with a possibly empty sequence of the following operators: “*” (dereference), “.” (field selection), and “ ⁇ >” (dereference and field selection).
- two access paths are “must-aliases” at a statement S if they refer to the same storage location in all execution instances of S.
- Two access paths are “may-aliases” at S if they refer to the same storage location in some execution instances of S.
- Pointer analysis has been found to be useful in understanding potential reachability connections between objects or references to objects. Recently, there has been a fair amount of work in developing algorithms for escape analysis of objects in Java TM programs to determine whether objects are local to the methods where they are created. Escape analysis is a static analysis that determines whether the object is still alive after the call to the method or procedure that created the object. The importance of escape analysis can be appreciated with reference to object oriented languages such as C++ and Java TM, as their implementations often employ a garbage collector to assist in memory management. Java TM in particular relies on a garbage collector for heap-allocated objects. However garbage collectors are notoriously slow. Stack allocation of objects is one way to minimize garbage collection. It is an object of escape analysis to determine which objects can be stack allocated.
- escape analysis is to determine if an object is accessed only by a single thread during its lifetime in order to avoid unnecessary synchronization operations in a multithreaded or multiprocessor environment.
- a representative publication dealing with escape analysis is the document Escape Analysis for Object Oriented Languages. Application to Java TM, Blanchet, B., OOPSLA 99.
- PCG program call graph
- Preferred embodiments of the present invention teach an improved technique of data flow analysis using pointer analysis, which can be applied to improve the performance of generational garbage collection of heap memory.
- the invention provides a computer implemented method of data flow analysis.
- An executing computer program employs pointers. Objects are allocated in memory by the program, and the objects are referenced by the pointers. Sizes of the objects are statically calculated at allocation sites in the program.
- a pointer alias analysis of the program is performed in order to estimate object lifetimes, wherein the estimated object lifetimes do not exceed actual lifetimes of the respective objects. Responsive to the pointer alias analysis and the static size calculation, the objects are assigned, or promoted, to an old generation or, in general, to any of an arbitrary number of generations which vary in age.
- Pointer analysis has been the focus of many research works in the last couple of years, and there are many practical methods for representing and computing inter-procedural aliases for a program written in a language that includes pointers.
- Most implementations adopt an “upper-bound” approach for representing points-to information: They address all possible reachability connections that may happen in execution instances. This is done in order to ensure safety usage of the pointer analysis results.
- An advantage of some aspects of the invention is the improved estimation of object lifetimes. It is known that the age distribution of objects exceeding about 50 kb is nearly flat. This, and the fact that more copying of such large objects takes place are further reasons to be aware of object lifetimes.
- the pointer alias analysis includes flow-sensitive analysis.
- an alias graph is iteratively constructed during the step of performing the pointer alias analysis until the alias graph is stable.
- the alias graph is constructed by constructing a control flow graph for each analyzable element of the program.
- a hierarchy graph and a call graph are constructed for each analyzed code segment to determine the caller-callee relationships in the program.
- a reachability graph is constructed for representing references to objects created at allocation sites.
- assignment is performed by locating possible garbage collection points in the code using the reachability graph. Paths are identified which extend from the allocation sites to the possible garbage collection points. The sizes of the objects are summed over the paths, and the objects are assigned to appropriate generations responsive to the summed sizes.
- the step of assigning the objects to generations is performed by calculating a space that is allocated by each basic block of the program.
- the space for each block is accumulated and propagated, using in/out equations, and the objects are assigned responsive to the propagated accumulated space.
- the step of calculating sizes further includes the step of detecting dynamic loading of a class or, alternatively or additionally, detecting dynamic instantiation of an object, or detecting dynamic invocation of a method.
- the pointer alias analysis may include either measuring a lower bound value of an object lifetime, measuring an upper bound value of an object lifetime, or measuring a value of an object lifetime that is intermediate an upper bound value thereof and a lower bound value thereof.
- the invention also provides a method of data flow analysis, including the steps of executing a program on a computer, determining a first point in the program that includes an allocation site of an object that is allocated on a heap memory, statically determining a second point in the program at which a given reachability criterion is satisfied with respect to the object, and statically computing the total amount of heap memory allocated on a path between the first point and the second point.
- the reachability criterion specifies that there is no reachable connection to the object at the second point.
- the reachability criterion specifies a heuristic likelihood of existence of a reachable connection to the object at the second point.
- the object Responsive to the total amount of the heap memory, the object is assigned to one of a first group and a second group. In some embodiments there may be many groups to which the object can be assigned.
- the step of determining the second point is performed by pointer analysis.
- the pointer analysis includes the steps of constructing a control flow graph for an analyzable element of the program, constructing a hierarchy graph for each analyzable element, and constructing a call graph for the analyzable elements. Responsive to the control flow graph, the hierarchy graph and the call graph, a reachability graph is constructed for the analyzable elements.
- static computation of object size is terminated when a computed lifetime exceeds a predetermined value.
- the step of statically determining a path to the second point is performed by identifying loops in the program that contain instructions for allocating the heap memory, and estimating a lower bound on a number of iterations traversed in the loops.
- the step of statically determining the second point is performed by predicting at least one frequently taken branch in the program, wherein the computation of the total amount of the heap memory is limited to the least frequently taken branch.
- the methods according to the invention can be realized in a computer software product and executed on a general purpose computer with the computer software product resident therein.
- FIG. 1 is a block diagram of a computer suitable for use in practicing the present invention
- FIGS. 2 and 3 are exemplary reachability graphs
- FIG. 4 is a high level flow chart illustrating a method for estimating object lifetimes according to the invention.
- FIG. 5 is an exemplary program flow graph according to the method illustrated in FIG. 4;
- FIG. 6 is an exemplary reachability graph
- FIG. 7 is an exemplary program hierarchy graph, used in the performance of the method depicted in FIG. 4;
- FIG. 8 is an exemplary program call graph according to the method illustrated in FIG. 4.
- FIG. 9 is a flow chart illustrating a technique for the static estimation of object lifetime.
- object lifetimes are measured by the number of bytes allocated on the heap, as is customary in the art of garbage collection. This is a practical metric because the number of allocated bytes correlates with the amount of work that must be invested by the allocator and by the garbage collector.
- FIG. 1 a block diagram of a computer system 10 .
- the system includes a conventional computer 12 , in which a memory 14 comprises a program section 16 that stores operating system programs, executing application programs and various runtime support modules for the programs as are known to the art.
- the memory 14 also includes a data section 18 which stores various data objects that may be generated by the executing programs.
- the data section 18 is allocated into a stack 20 and a heap 22 . While the memory 14 is shown as a single memory for clarity, many variations in its organization and physical type are possible. For example there may be a plurality of stacks.
- the various components of the memory 14 may also be physically separate according to the architecture of the particular computer 12 .
- the computer 12 is provided with a peripheral device 24 which accepts computer software products.
- a computer language 26 or runtime support therefor, may be installed in the computer 12 via the peripheral device 24 .
- the computer language 26 employs heap allocation of data objects and utilizes generational garbage collection.
- the computer language 26 is preferably Java TM or a modification thereof, but can be any language that utilizes pointers and heap allocation of data objects.
- the computer language 26 manages the heap 22 using a generational garbage collection algorithm.
- objects are allocated on the heap 22 and references are defined elsewhere in the memory 14 to point to them.
- An object is considered to be “alive” as long as it is reachable from some runtime data area via a chain of references.
- the purpose of a garbage collector is to reclaim unreachable objects in heap memory. Generational garbage collection is based on the observation that heap-allocated objects are typically short-lived. Thus, garbage collection will be more efficient if efforts are concentrated on the most recently allocated, or youngest objects. Objects in the heap are grouped according to age, such that younger groups can be collected more frequently and older groups less often.
- Pointer alias analysis is assisted by a graph notation.
- the oval nodes 28 represent objects or references to objects.
- Rectangular nodes 30 represent variables or instance fields, and the edges 32 represent reachability connections between any of the objects, references to objects, variables and instance fields.
- FIG. 5 The algorithm for object lifetime estimation is disclosed with reference to FIG. 4.
- a program is accepted, for example the program shown in Listing 1 .
- This program is represented graphically by FIG. 5.
- Listing 1 void static main (. . . .) ⁇ //Begin block 36 (FIG. 5)
- T hop new T1 ( . . . ) ;
- T tmp hop;
- T1 pop new T ( . . .
- control flow graph is constructed for each analyzable element, such as method, function, procedure or the like, of the code being analyzed, according to the specification of the particular computer language being evaluated.
- the control flow graphs are used to facilitate intra-procedural reachability analysis, and intra-procedural size computation.
- hierarchy and call graphs are built for the analyzed code.
- a reachability analysis is performed for each instruction in the program, as well as at the entrance to and exit from each basic block.
- Reachability graphs are thus built to represent the references between live variables and objects generated at the allocation sites. Such graphs are shown in FIGS. 2 - 3 . As mentioned above, these reachability graphs differs from conventional reachability graphs that represent an upper bound view.
- step 48 for each allocation site representing the generation of a particular object the lifetime of the object is statically estimated, as described in detail hereinbelow. The algorithm then terminates at step 50 .
- FIG. 5 shows the development of the control flow graph of T.main( ).
- a T 1 object is allocated prior to reaching the for loop in T.main( ).
- An allocation site for a T object is found within the for loop of T.main( ), as indicated at block 38 .
- the basic block following the for loop is indicated by block 40 , and the control flow graph is complete at block 52 .
- the hierarchy graph 54 provides information on the overriding relationships which is needed in order to build the program call graph 56 .
- the hierarchy graph 54 also provides information on inheritance relationships in order to compute object size at each allocation site.
- the call graph 56 is used for interprocedural reachability analysis and interprocedural size computation.
- FIG. 2 shows a reachability graph 58 which applies at the conclusion of block 36 .
- FIG. 6 shows a reachability graph 60 which applies while the program is executing in block 38 .
- FIG. 3 shows a reachability graph 62 which applies at the conclusion of block 38 .
- the reachability graphs 58 , 60 , 62 graphs model reachability relationships, i.e., the paths from variables to objects, and vice versa. These graphs have similarities to other known pointer reference graphs, such as alias graphs, points-to graphs and connection graphs. Nevertheless, they differ from traditional graphs that represent an upper bound view. As mentioned above, it is intended to capture lower bound views as well as upper bound views. Conventionally reference graphs represent reachability relations that could possibly occur. In contrast, in the potential lower bound view, the graph, generated at a given point in the code, has an edge between nodes, only if we are absolutely sure that there is a reachability relation between those references or objects at the given point.
- the reachability graphs 58 , 60 , 62 are used to locate the earliest point at which there may be no live reference to an object.
- the pointer alias analysis identifies some program point for which in the corresponding graph there would be no reference pointing to that object node. This program point is used to approximate a lower bound on the lifetime of objects.
- Step 64 the procedure begins.
- Step 66 represents an analysis according to a preferred embodiment of the invention to locate possible garbage collection points where an object may have no live references pointing to it.
- both lower bound views as well as upper bound views are captured.
- the reachability graphs represent reachability relationships that may in fact happen.
- the reachability graph, generated at a given point in the code has an edge between nodes only if there is certainty that there is a reachability relation between the references or objects at that point.
- step 66 possible garbage collection points are located in the code using the reachability graphs which were constructed al step 46 .
- an object may have no live references pointing to it, and is not subsequently referenced or used.
- step 68 the paths extending from the allocation sites to the possible garbage collection points are evaluated, and the size of each newly generated object on the paths are calculated.
- step 68 in some embodiments the typing characteristics of Java are exploited, wherein it is possible to statically calculate the size of objects being created at allocation sites. Size manipulation is done on the flow graph by calculating the space allocated at each basic block, using some of the information generated by the pointer analysis, and then propagating iteratively the accumulated space with appropriate in/out equations. During interprocedural analysis the allocated size is maintained with each method. The process of FIG. 9 is complete at step 70 .
- T is the class shown in Listing 1 .
- Java TM which allow late bindings and interpretation.
- These features can result in actions that cannot be detected statically. Examples of such features are those constructs that enable dynamic loading, instantiation and method invocations.
- the technique according to the invention attempts to detect all those anomalies. Size manipulation is done on the flow graph by calculating the space allocated at each basic block, using some of the information generated by the pointer analysis and then iteratively propagating the accumulated space with the appropriate in/out equations.
- the allocated size is maintained in association with each method.
- Static techniques for recognizing such places may include: (i) Searching for loops that contain instructions for allocating heap space and estimating a lower bound on the number of iterations traversed in such loops. (ii) Using branch prediction information to find the most frequently used computation paths. This set of paths can be used for estimating the allocated area and the lifetime of some objects.
- Objects that were generated before the entry to “hot spots” are recognized using the second heuristic. They are marked as being old if they will last after the exit from a “heavy” hot spot. It is known that a lifetime of over a few megabytes causes an object to be assigned to an old generation during generational garbage collection. Such information can be exploited to limit the process of determining the size of an object once it is realized that the object exceeds a threshold value.
Abstract
Description
- 1. Field of the Invention
- This invention relates to computational methods. More particularly this invention relates to the static analysis of the lifetimes of heap-allocated objects in functioning computer programs and the application of this analysis to generational garbage collection of heap memory.
- 2. Description of the Related Art
- Current generational schemes of garbage collection allocate newly created objects on the heap to the youngest generation. If such an object survives a certain number of collections of that generation, it is promoted to an older generation. Older generations are collected less often. Promotion overhead continues to be paid until the object is either collected or it resides in the oldest generation. Generational garbage collection can be combined with various collection schemes, e.g., copying collection, mark-sweep collection, and the amount of overhead depends on the specific scheme.
- For example, the primary overhead for a copying generational garbage collection, is the repeated copying of the object until it reaches the oldest generation.
- In previous work, profiling of information has been proposed to estimate object lifetime. That estimation has then been used dynamically during the course of collection cycles to choose the proper generation in which to allocate the object. This scheme has been shown to indeed avoid the overhead associated with allocating a long-lived object in the youngest generation and then promoting it to an older generation. But this technique has significant drawbacks and incurs considerable runtime overhead. Profiling involves program instrumentation in order to train executions of a program, and further requires collecting and storing the results for later use. Such a process slows down the execution time, sometime by two order of magnitude, and is impractical for large programs. In addition, the results depends on the training input set.
- The documentGenerational Stack Collection and Profile-Driven Pretenuring, P. Cheng, R. Harper, and P. Lee, PLDI '98 pp. 162-173. proposes to use profiling to find object lifetimes and employ that information in order to improve a copying generational garbage collector. It discloses an average decrease of 30% in generational garbage collection time, through the avoidance of copying of data from generation to generation. It was noted that a few allocation sites consistently produce data that survive many allocations.
- Recently the documentA Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks, S. Dieckmann, and Urs Holzle, Proceedings of the 13th European Conference on Object-Oriented Programming (ECOOP'99), Lisbon, June 1999, Springer Verlag, reports that 1%-40% of SPECjvm98 objects are still live after 100 Kbytes, with jess having the lower range and db on the upper end. Even after one megabyte of allocations, 21% of all allocated bytes are still live in javac, 12% in db and 8% in jack. These graphs show a flat age distribution after a drop at about 50 kbytes lasting until the end of the application. The possibility of eliminating expensive copying of large objects makes knowledge of object lifetime especially beneficial.
- In other approaches attempts have been made to increase the efficiency of data flow analysis. Data flow analysis computes information about the potential behavior of a program in terms of the definitions and uses of data objects. Such data flow information is important for optimizing compilers, program environments, and understanding tools. It can also be used in a software-testing system or to provide compiler and runtime support for the parallel execution of programs originally written in sequential languages.
- Numerous techniques have been successfully developed for data flow analysis of programs written in languages with only static data structures, such as Fortran. However, data flow analysis for programs written in languages with dynamically allocated data structures, such as C, C++, Fortran 90, Java ™, and LISP, is more challenging because of pointer-induced aliasing, which occurs when two or more pointer expressions refer to the same storage location.
- Aliasing occurs when there exists more than one access path to a storage location. An access path is constructed from variables, pointer dereference operators, and structure field selection operators. In C such an expression would include a variable with a possibly empty sequence of the following operators: “*” (dereference), “.” (field selection), and “−>” (dereference and field selection). For purposes of pointer alias analysis, two access paths are “must-aliases” at a statement S if they refer to the same storage location in all execution instances of S. Two access paths are “may-aliases” at S if they refer to the same storage location in some execution instances of S.
- A number of factors are known to influence the cost and precision of practical pointer alias analysis, including the use of flow sensitivity techniques, the use of context sensitivity, the manner in which aggregate data objects such as arrays and classes are modeled, the modeling of the heap, and the choice of alias representation. It is known that there is no general solution to the problem of pointer alias analysis, and the art has therefore attempted to improve the efficiency of the analysis using a variety of empirical and theoretical techniques and combinations. The document,Interprocedural Pointer Alias Analysis, Hind, Michael et al., ACM Transactions on Programming Languages, Vol. 21, No. 4, July 1999, proposes one combined approach to the analysis of pointer aliasing.
- Pointer analysis has been found to be useful in understanding potential reachability connections between objects or references to objects. Recently, there has been a fair amount of work in developing algorithms for escape analysis of objects in Java ™ programs to determine whether objects are local to the methods where they are created. Escape analysis is a static analysis that determines whether the object is still alive after the call to the method or procedure that created the object. The importance of escape analysis can be appreciated with reference to object oriented languages such as C++ and Java ™, as their implementations often employ a garbage collector to assist in memory management. Java ™ in particular relies on a garbage collector for heap-allocated objects. However garbage collectors are notoriously slow. Stack allocation of objects is one way to minimize garbage collection. It is an object of escape analysis to determine which objects can be stack allocated. A further use of escape analysis is to determine if an object is accessed only by a single thread during its lifetime in order to avoid unnecessary synchronization operations in a multithreaded or multiprocessor environment. A representative publication dealing with escape analysis is the documentEscape Analysis for Object Oriented Languages. Application to Java ™, Blanchet, B., OOPSLA 99.
- The following two papers present various techniques that statically analyze objects in Java programs to determine whether they are local to the methods where they are created. These algorithms suggest various mapping techniques in applying escape analysis to reachability problems.
- The documentEscape Analysis for Java, J. D. Choi, M. Gupta, M. Serrano, V. O. Sreedhar, and S. Midkiff, OOPSLA '99, pp. 1-19. reports that reachability and escape analysis specifies over 70% of all dynamically created objects as objects that may be allocated on the stack in three out of the ten benchmarks.
- The documentRemoving Unnecessary Synchronization in Java, J. Bogda, and U. Holzle, OOPSLA '99, pp. 20-34 discloses a static evaluation of escape analysis. The authors determined the percentage of candidate alias sets that were optimized. An ideal analysis, having no loss of precision, would reach 100% for a single threaded application. For the programs in their benchmark suite (compress, db, jack, javac, jess, mpegaudio, mtrt from SPECJvm98 in addition to sort and javacup), the analysis was found to optimize between 91% and 96% of candidate alias sets.
- Interprocedural data flow analyses make use of the program call graph (PCG), which is a flow multigraph in which each procedure is represented by a single node and in which an edge represents a potential call of a procedure from a call site of another procedure. In the presence of function pointers or virtual methods a call site may contribute multiple edges to different procedures.
- There are many known methods for representing and computing interprocedural aliases for a program written in a language that includes pointers. Basically, during an interprocedural iteration, each procedure is visited, and intermediate intraprocedural information for the procedure is computed. This information is then used to update corresponding interprocedural information.
- Preferred embodiments of the present invention teach an improved technique of data flow analysis using pointer analysis, which can be applied to improve the performance of generational garbage collection of heap memory.
- The invention provides a computer implemented method of data flow analysis. An executing computer program employs pointers. Objects are allocated in memory by the program, and the objects are referenced by the pointers. Sizes of the objects are statically calculated at allocation sites in the program. A pointer alias analysis of the program is performed in order to estimate object lifetimes, wherein the estimated object lifetimes do not exceed actual lifetimes of the respective objects. Responsive to the pointer alias analysis and the static size calculation, the objects are assigned, or promoted, to an old generation or, in general, to any of an arbitrary number of generations which vary in age.
- Pointer analysis has been the focus of many research works in the last couple of years, and there are many practical methods for representing and computing inter-procedural aliases for a program written in a language that includes pointers. Most implementations adopt an “upper-bound” approach for representing points-to information: They address all possible reachability connections that may happen in execution instances. This is done in order to ensure safety usage of the pointer analysis results.
- In the context of this disclosure, there is no question of safety. There is only time-space tradeoff. At one extreme, in some embodiments the analysis is used very conservatively, in the sense that for every possible object that may be allocated during runtime, the statically estimated lifetime never exceeds the actual lifetime. In other words, a lower bound on the actual object lifetime is being sought. Such lower bound estimations might be too conservative and can result in insufficient reduction in the garbage collection overhead. At the other end, in other embodiments it may be chosen to promote an object to an older generation when the statically-estimated lifetime is computed as an upper bound, i.e. there is a computation path for which the estimated lifetime is correct.
- Certain heuristics are adopted in order to control the various approaches. Lower bound, upper bound and “middle” estimations are handled by the heuristics. Using static branch predictor and the generation of “middle” estimations are suggested to give even better results.
- An advantage of some aspects of the invention is the improved estimation of object lifetimes. It is known that the age distribution of objects exceeding about 50 kb is nearly flat. This, and the fact that more copying of such large objects takes place are further reasons to be aware of object lifetimes.
- The application of some aspects of the invention result in a significant improvement in the static analysis of object lifetime to reduce garbage collection overhead.
- These and other advantages of the present invention are attained by a technique for efficiently identifying objects that will persist for long periods of time. In an environment in which generational garbage collection is employed, exploitation of the knowledge of object lifetimes reduces the cost of repeatedly promoting the objects to older generations.
- According to an aspect of the invention, the pointer alias analysis includes flow-sensitive analysis.
- According to an additional aspect of the invention, an alias graph is iteratively constructed during the step of performing the pointer alias analysis until the alias graph is stable.
- According to a further aspect of the invention, the alias graph is constructed by constructing a control flow graph for each analyzable element of the program. A hierarchy graph and a call graph are constructed for each analyzed code segment to determine the caller-callee relationships in the program. At each point in the code, a reachability graph is constructed for representing references to objects created at allocation sites.
- According to yet another aspect of the invention, assignment is performed by locating possible garbage collection points in the code using the reachability graph. Paths are identified which extend from the allocation sites to the possible garbage collection points. The sizes of the objects are summed over the paths, and the objects are assigned to appropriate generations responsive to the summed sizes.
- In another aspect of the invention, the step of assigning the objects to generations is performed by calculating a space that is allocated by each basic block of the program. The space for each block is accumulated and propagated, using in/out equations, and the objects are assigned responsive to the propagated accumulated space.
- Preferably, the step of calculating sizes further includes the step of detecting dynamic loading of a class or, alternatively or additionally, detecting dynamic instantiation of an object, or detecting dynamic invocation of a method.
- The pointer alias analysis may include either measuring a lower bound value of an object lifetime, measuring an upper bound value of an object lifetime, or measuring a value of an object lifetime that is intermediate an upper bound value thereof and a lower bound value thereof.
- Although in preferred embodiments of the present invention, the methods of analysis described herein are used in promoting one or more of the objects to an older generation for purposes of garbage collection, the principles of the present invention may also be used to group the objects for other purposes.
- The invention also provides a method of data flow analysis, including the steps of executing a program on a computer, determining a first point in the program that includes an allocation site of an object that is allocated on a heap memory, statically determining a second point in the program at which a given reachability criterion is satisfied with respect to the object, and statically computing the total amount of heap memory allocated on a path between the first point and the second point.
- Preferably, the reachability criterion specifies that there is no reachable connection to the object at the second point. Alternatively, the reachability criterion specifies a heuristic likelihood of existence of a reachable connection to the object at the second point.
- Responsive to the total amount of the heap memory, the object is assigned to one of a first group and a second group. In some embodiments there may be many groups to which the object can be assigned.
- According to another aspect of the invention, the step of determining the second point is performed by pointer analysis. The pointer analysis includes the steps of constructing a control flow graph for an analyzable element of the program, constructing a hierarchy graph for each analyzable element, and constructing a call graph for the analyzable elements. Responsive to the control flow graph, the hierarchy graph and the call graph, a reachability graph is constructed for the analyzable elements.
- According to a further aspect of the invention, static computation of object size is terminated when a computed lifetime exceeds a predetermined value.
- According to an aspect of the invention, the step of statically determining a path to the second point is performed by identifying loops in the program that contain instructions for allocating the heap memory, and estimating a lower bound on a number of iterations traversed in the loops.
- According to another aspect of the invention, the step of statically determining the second point is performed by predicting at least one frequently taken branch in the program, wherein the computation of the total amount of the heap memory is limited to the least frequently taken branch.
- The methods according to the invention can be realized in a computer software product and executed on a general purpose computer with the computer software product resident therein.
- For a better understanding of these and other objects of the present invention, reference is made to the detailed description of the invention, by way of example, which is to be read in conjunction with the following drawings, wherein:
- FIG. 1 is a block diagram of a computer suitable for use in practicing the present invention;
- FIGS. 2 and 3 are exemplary reachability graphs;
- FIG. 4 is a high level flow chart illustrating a method for estimating object lifetimes according to the invention;
- FIG. 5 is an exemplary program flow graph according to the method illustrated in FIG. 4;
- FIG. 6 is an exemplary reachability graph;
- FIG. 7 is an exemplary program hierarchy graph, used in the performance of the method depicted in FIG. 4;
- FIG. 8 is an exemplary program call graph according to the method illustrated in FIG. 4; and
- FIG. 9 is a flow chart illustrating a technique for the static estimation of object lifetime.
- In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances well known, control logic, and the details of computer program instructions for conventional algorithms and processes have not been shown in detail in order not to unnecessarily obscure the present invention.
- As used herein, object lifetimes are measured by the number of bytes allocated on the heap, as is customary in the art of garbage collection. This is a practical metric because the number of allocated bytes correlates with the amount of work that must be invested by the allocator and by the garbage collector.
- Turning now to the drawings and in particular to FIG. 1 there is shown a block diagram of a
computer system 10. The system includes a conventional computer 12, in which amemory 14 comprises aprogram section 16 that stores operating system programs, executing application programs and various runtime support modules for the programs as are known to the art. Thememory 14 also includes a data section 18 which stores various data objects that may be generated by the executing programs. The data section 18 is allocated into astack 20 and a heap 22. While thememory 14 is shown as a single memory for clarity, many variations in its organization and physical type are possible. For example there may be a plurality of stacks. The various components of thememory 14 may also be physically separate according to the architecture of the particular computer 12. The computer 12 is provided with aperipheral device 24 which accepts computer software products. Acomputer language 26, or runtime support therefor, may be installed in the computer 12 via theperipheral device 24. According to a preferred embodiment of the invention, thecomputer language 26 employs heap allocation of data objects and utilizes generational garbage collection. Thecomputer language 26 is preferably Java ™ or a modification thereof, but can be any language that utilizes pointers and heap allocation of data objects. Thecomputer language 26 manages the heap 22 using a generational garbage collection algorithm. - As a program executes in the
computer system 10 objects are allocated on the heap 22 and references are defined elsewhere in thememory 14 to point to them. An object is considered to be “alive” as long as it is reachable from some runtime data area via a chain of references. The purpose of a garbage collector is to reclaim unreachable objects in heap memory. Generational garbage collection is based on the observation that heap-allocated objects are typically short-lived. Thus, garbage collection will be more efficient if efforts are concentrated on the most recently allocated, or youngest objects. Objects in the heap are grouped according to age, such that younger groups can be collected more frequently and older groups less often. By estimating object lifetime, it is possible to reduce the overhead of allocating a long-lived object to the youngest generation, and then promoting it to an older generation. According to the preferred embodiment of the invention, this is accomplished through static program analysis. The technique for statically estimating the object lifetime combines two major components: - 1. The use of pointer analysis to manipulate potential reachability connections between objects or references to objects. The results of this analysis will be used to detect points in the program where there may be no more references pointing to a particular object. In other words, the event that an object may possibly have ceased to be alive is statically identified. These points are referred to herein as possible garbage collection points.
- 2. Static calculation of the size of an object being created at some allocation site. When, as in Java, the definition of objects is fully typed, it is possible to statically calculate the size of objects being created at their allocation sites. In Java, the case of allocating an array is an exception, as the number of the array components is not always known statically. As mentioned above, pointer analysis has been the focus of many recent research works, and there are many known methods for representing and computing interprocedural aliases for a program written in a language that includes pointers. All implementations known to the inventors adopt an “upper-bound” approach for representing points-to information. In other words prior art implementations address all possible reachability connections that may happen in execution instances. This is done in order to ensure the safe usage of the pointer analysis results.
- In applying the invention, there is a time-space tradeoff. At one extreme, we may use the analysis very conservatively in the sense that for every possible object that may be allocated during runtime, the statically-estimated lifetime never exceeds the actual lifetime. In other words, the analysis attempts to determine a lower bound on the actual object lifetime. Such lower bound estimations might be too conservative and could result in insufficient reduction in the garbage collection overhead. At the other extreme, we can choose to promote an object to an older generation whenever there is any computation path for which the statically estimated object lifetime is correct. This is what is meant by an upper bound on the actual object lifetime.
- Certain heuristics have been adopted in order to control the parameters of the analysis within the time-space tradeoff spectrum. In a preferred embodiment it is possible to produce both lower bound, upper bound and intermediate estimations. In some preferred embodiments the use of static branch prediction, followed by the generation of the intermediate estimates may be advantageous.
- Pointer alias analysis is assisted by a graph notation. In the reachability graphs shown in FIGS.2-3, the
oval nodes 28 represent objects or references to objects.Rectangular nodes 30 represent variables or instance fields, and theedges 32 represent reachability connections between any of the objects, references to objects, variables and instance fields. - The algorithm for object lifetime estimation is disclosed with reference to FIG. 4. At step34 a program is accepted, for example the program shown in
Listing 1. This program is represented graphically by FIG. 5.Listing 1void static main (. . . .) { //Begin block 36 (FIG. 5) T hop =new T1 ( . . . ) ; T tmp = hop; tmp.data1 = 5; // End block 36//Point in code corresponding to the reachability //graph of FIG. 2 // Begin block 38for (int i = 0; i < 10; i++) { T1 pop =new T ( . . . ) ; T1 z=pop; z.foo () ; . . . //Point in code corresponding to the reachability //graph of FIG. 6 pop = null; z = null; } // End block 38//Point in code corresponding to the reachability //graph of FIG. 3 //Begin block 40 z = hop; tmp = pop; //End block 40 } class T extends T1 { int data; void foo() { . . . } } class T1 { int data1; void foo () { . . . } } - At step42 a control flow graph is constructed for each analyzable element, such as method, function, procedure or the like, of the code being analyzed, according to the specification of the particular computer language being evaluated. The control flow graphs are used to facilitate intra-procedural reachability analysis, and intra-procedural size computation. Next, at
step 44, hierarchy and call graphs are built for the analyzed code. - Then at
step 46, a reachability analysis is performed for each instruction in the program, as well as at the entrance to and exit from each basic block. Reachability graphs are thus built to represent the references between live variables and objects generated at the allocation sites. Such graphs are shown in FIGS. 2-3. As mentioned above, these reachability graphs differs from conventional reachability graphs that represent an upper bound view. - At
step 48 for each allocation site representing the generation of a particular object, the lifetime of the object is statically estimated, as described in detail hereinbelow. The algorithm then terminates atstep 50. - The construction of the control flow graph at
step 42 is explained in further detail with reference to FIG. 5 andListing 1. FIG. 5 shows the development of the control flow graph of T.main( ). At block 36 a T1 object is allocated prior to reaching the for loop in T.main( ). An allocation site for a T object is found within the for loop of T.main( ), as indicated atblock 38. The basic block following the for loop is indicated byblock 40, and the control flow graph is complete atblock 52. - Referring to FIGS. 4, 5,7, 8 and
Listing 1, the preparation of the hierarchy graph and the call graph of the program atstep 44 are shown. Thehierarchy graph 54 provides information on the overriding relationships which is needed in order to build theprogram call graph 56. Thehierarchy graph 54 also provides information on inheritance relationships in order to compute object size at each allocation site. Thecall graph 56 is used for interprocedural reachability analysis and interprocedural size computation. - With reference to FIGS.2-6 and
Listing 1, the construction of the reachability graphs ofstep 46 is explained in further detail FIG. 2 shows areachability graph 58 which applies at the conclusion ofblock 36. FIG. 6 shows areachability graph 60 which applies while the program is executing inblock 38. FIG. 3 shows areachability graph 62 which applies at the conclusion ofblock 38. - The
reachability graphs reachability graphs - Referring now to FIGS. 3, 4,5, 6, and 9, the method of statically estimating the object lifetime in
step 48 is disclosed in further detail. Atstep 64 the procedure begins.Step 66 represents an analysis according to a preferred embodiment of the invention to locate possible garbage collection points where an object may have no live references pointing to it. In some preferred embodiments both lower bound views as well as upper bound views are captured. In some embodiments the reachability graphs represent reachability relationships that may in fact happen. In other embodiments, in the potential lower bound views, the reachability graph, generated at a given point in the code, has an edge between nodes only if there is certainty that there is a reachability relation between the references or objects at that point. - At
step 66 possible garbage collection points are located in the code using the reachability graphs which were constructedal step 46. At each possible garbage collection point an object may have no live references pointing to it, and is not subsequently referenced or used. - At
step 68 the paths extending from the allocation sites to the possible garbage collection points are evaluated, and the size of each newly generated object on the paths are calculated. Instep 68 in some embodiments the typing characteristics of Java are exploited, wherein it is possible to statically calculate the size of objects being created at allocation sites. Size manipulation is done on the flow graph by calculating the space allocated at each basic block, using some of the information generated by the pointer analysis, and then propagating iteratively the accumulated space with appropriate in/out equations. During interprocedural analysis the allocated size is maintained with each method. The process of FIG. 9 is complete atstep 70. - For example, in FIG. 3, at the end of
block 38 there are no references to the node representing the objects generated inblock 38. Inblock 40, the lifetime of the object generated inblock 36 is measured by its size, given by: - (number of iterations) * (size of T=2 * size of(int))=20 * (size of int),
- where T is the class shown in
Listing 1. There is inevitable imprecision in the static analysis of languages such as Java ™, which allow late bindings and interpretation. These features can result in actions that cannot be detected statically. Examples of such features are those constructs that enable dynamic loading, instantiation and method invocations. The technique according to the invention attempts to detect all those anomalies. Size manipulation is done on the flow graph by calculating the space allocated at each basic block, using some of the information generated by the pointer analysis and then iteratively propagating the accumulated space with the appropriate in/out equations. - For the interprocedural analysis the allocated size is maintained in association with each method.
- There is a time-space trade-off between the safe approach in which the object lifetime is never overestimated, and the unsafe approach, in which overestimation can occur. Overestimation results in a space cost, as space is consumed in maintaining old generations. Underestimation costs time due to the overhead of manipulating long lived objects by the garbage collector.
- There are heuristics which are applied to optimizing the time-space tradeoff:
- 1. Relaxing the strength of the analysis. This can be implemented by keeping less information during the analysis, or by computing non-lower bound values, or by ignoring some computation paths that are unlikely to be used during successful runs.
- 2. Selecting the most promising places that generate long lived objects. Static techniques for recognizing such places may include: (i) Searching for loops that contain instructions for allocating heap space and estimating a lower bound on the number of iterations traversed in such loops. (ii) Using branch prediction information to find the most frequently used computation paths. This set of paths can be used for estimating the allocated area and the lifetime of some objects.
- Objects that were generated before the entry to “hot spots” are recognized using the second heuristic. They are marked as being old if they will last after the exit from a “heavy” hot spot. It is known that a lifetime of over a few megabytes causes an object to be assigned to an old generation during generational garbage collection. Such information can be exploited to limit the process of determining the size of an object once it is realized that the object exceeds a threshold value.
- Dieckmann et al. have reported in their above noted publication that the reference density distribution is relatively high: In spite of this observation they claim that SPECjvm98 programs are good candidates for generational garbage collection, although not as good as the small programs studied earlier. In some preferred embodiments of the invention an additional analysis for recognizing references from the old objects found to other objects in the heap may be added. This will enable a simple inexpensive handling of those references during escape analysis.
- We have disclosed herein a technique for the static estimation of object lifetimes, which finds application in the optimization of generational garbage collection. Reduction of garbage collection runtime overhead may be crucial in accepting newer languages such as Java ™. According to the invention pointer analysis is combined with object size measurement in order to estimate the amount of heap allocated from the time an object is allocated until the time that it is no longer reachable.
- While this invention has been explained with reference to the structure disclosed herein, it is not confined to the details set forth and this application is to cover any modifications and changes as may within the scope of the following claims:
Claims (46)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/751,566 US6457023B1 (en) | 2000-12-28 | 2000-12-28 | Estimation of object lifetime using static analysis |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/751,566 US6457023B1 (en) | 2000-12-28 | 2000-12-28 | Estimation of object lifetime using static analysis |
Publications (2)
Publication Number | Publication Date |
---|---|
US20020129343A1 true US20020129343A1 (en) | 2002-09-12 |
US6457023B1 US6457023B1 (en) | 2002-09-24 |
Family
ID=25022578
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/751,566 Expired - Lifetime US6457023B1 (en) | 2000-12-28 | 2000-12-28 | Estimation of object lifetime using static analysis |
Country Status (1)
Country | Link |
---|---|
US (1) | US6457023B1 (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030023768A1 (en) * | 2001-07-24 | 2003-01-30 | Foti David A. | Designating an object for destruction |
US20050015752A1 (en) * | 2003-07-15 | 2005-01-20 | International Business Machines Corporation | Static analysis based error reduction for software applications |
US20050229044A1 (en) * | 2003-10-23 | 2005-10-13 | Microsoft Corporation | Predicate-based test coverage and generation |
US20070169124A1 (en) * | 2005-11-10 | 2007-07-19 | Aaron Kershenbaum | Method, system and program product for detecting and managing unwanted synchronization |
US20070174370A1 (en) * | 2006-01-12 | 2007-07-26 | Sun Microsystems, Inc. | Method and apparatus for decreasing object copying by a generational, copying garbage collector |
US20070226698A1 (en) * | 2006-03-27 | 2007-09-27 | International Business Machines Corporation | Method for improving performance of executable code |
WO2008112422A1 (en) * | 2007-03-14 | 2008-09-18 | Nec Laboratories America, Inc. | System and method for scalable flow and context-sensitive pointer alias analysis |
US20080313624A1 (en) * | 2004-10-01 | 2008-12-18 | Sony Computer Entertainment Inc. | Dynamic loading and unloading for processing unit |
US20090094588A1 (en) * | 2003-09-25 | 2009-04-09 | Lantronix, Inc. | Method and system for program transformation using flow-sensitive type constraint analysis |
US20100162219A1 (en) * | 2007-06-04 | 2010-06-24 | International Business Machines Corporation | Diagnosing Aliasing Violations in a Partial Program View |
US20100175053A1 (en) * | 2007-06-21 | 2010-07-08 | Nxp B.V. | Device and a method of managing a plurality of software items |
US20120133654A1 (en) * | 2006-09-19 | 2012-05-31 | Caustic Graphics Inc. | Variable-sized concurrent grouping for multiprocessing |
WO2013036701A2 (en) | 2011-09-09 | 2013-03-14 | Microsoft Corporation | Managing object lifetime in a cyclic graph |
US8578389B1 (en) * | 2004-05-04 | 2013-11-05 | Oracle America, Inc. | Method and system for merging directed acyclic graphs representing data flow codes |
US8819382B2 (en) | 2012-08-09 | 2014-08-26 | Apple Inc. | Split heap garbage collection |
US9239780B2 (en) | 2011-12-21 | 2016-01-19 | Samsung Electronics Co., Ltd. | Selection of memory blocks for garbage collection based on variable block life threshold |
US9514025B2 (en) * | 2015-04-15 | 2016-12-06 | International Business Machines Corporation | Modeling memory use of applications |
US9645923B1 (en) * | 2013-09-10 | 2017-05-09 | Google Inc. | Generational garbage collector on multiple heaps |
US20170139685A1 (en) * | 2014-06-25 | 2017-05-18 | Chengdu Puzhong Software Limted Company | Visual software modeling method to construct software views based on a software meta view |
US20170169212A1 (en) * | 2015-12-09 | 2017-06-15 | International Business Machines Corporation | Security enforcement in the presence of dynamic code loading |
US20170185504A1 (en) * | 2015-12-23 | 2017-06-29 | Oracle International Corporation | Scalable points-to analysis via multiple slicing |
US9934127B1 (en) | 2017-03-08 | 2018-04-03 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of key frames for replay responsiveness |
US9934126B1 (en) | 2017-03-08 | 2018-04-03 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of reverse lookup data structures |
US9940369B1 (en) | 2017-03-08 | 2018-04-10 | Microsoft Technology Licensing, Llc | Searching an indexed time-travel trace |
US9959194B1 (en) | 2017-03-08 | 2018-05-01 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of memory snapshots for replay responsiveness |
US9983978B1 (en) | 2017-03-08 | 2018-05-29 | Microsoft Technology Licensing, Llc | Querying an indexed time-travel trace |
US20180173728A1 (en) * | 2016-12-16 | 2018-06-21 | Fujitsu Limited | Information processing apparatus and method |
US20180336120A1 (en) * | 2017-05-18 | 2018-11-22 | International Business Machines Corporation | Streams analysis tool and method |
US10185645B2 (en) | 2017-03-08 | 2019-01-22 | Microsoft Technology Licensing, Llc | Resource lifetime analysis using a time-travel trace |
US10282274B2 (en) | 2017-06-14 | 2019-05-07 | Microsoft Technology Licensing, Llc | Presenting differences between code entity invocations |
US10296314B2 (en) * | 2016-11-01 | 2019-05-21 | Facebook, Inc. | Detecting and remedying memory leaks caused by object reference cycles |
US11210071B2 (en) * | 2020-04-01 | 2021-12-28 | Microsoft Technology Licensing, Llc | Compiler sub expression directed acyclic graph (DAG) remat for register pressure |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6813761B1 (en) * | 2000-06-30 | 2004-11-02 | Microsoft Corporation | Methods for enhancing flow analysis |
US6757890B1 (en) * | 2000-12-28 | 2004-06-29 | Sun Microsystems, Inc. | Methods and apparatus for enabling local Java object allocation and collection |
US6820101B2 (en) * | 2000-12-28 | 2004-11-16 | Sun Microsystems, Inc. | Methods and apparatus for optimizing garbage collection using separate heaps of memory for storing local objects and non-local objects |
US7111294B2 (en) * | 2001-01-16 | 2006-09-19 | Microsoft Corporation | Thread-specific heaps |
US7007270B2 (en) * | 2001-03-05 | 2006-02-28 | Cadence Design Systems, Inc. | Statistically based estimate of embedded software execution time |
US7458061B2 (en) * | 2002-06-14 | 2008-11-25 | Sun Microsystems, Inc. | Protecting object identity in a language with built-in synchronization objects |
US7072905B2 (en) * | 2002-12-06 | 2006-07-04 | Sun Microsystems, Inc. | Better placement of objects reachable from outside a generation managed by the train algorithm |
US7392514B2 (en) * | 2003-06-26 | 2008-06-24 | Microsoft Corporation | Data flow chasing |
US7089537B2 (en) * | 2003-09-15 | 2006-08-08 | Microsoft Corporation | System and method for performing path-sensitive value flow analysis on a program |
US7836434B1 (en) * | 2004-05-04 | 2010-11-16 | Oracle America, Inc. | Method and system for analyzing array access to a pointer that is referenced as an array |
US7149870B2 (en) * | 2004-06-04 | 2006-12-12 | International Business Machines Corporation | Assigning sections within a memory heap for efficient garbage collection of large objects |
US7376684B2 (en) | 2004-06-04 | 2008-05-20 | International Business Machines Corporation | Efficient parallel bitwise sweep during garbage collection |
US7149866B2 (en) * | 2004-06-04 | 2006-12-12 | International Business Machines Corporation | Free item distribution among multiple free lists during garbage collection for more efficient object allocation |
US7954100B1 (en) * | 2005-06-02 | 2011-05-31 | Oracle America, Inc. | Tagged references for thread-local data |
US8799882B2 (en) * | 2005-12-07 | 2014-08-05 | Microsoft Corporation | Compiler support for optimizing decomposed software transactional memory operations |
US8099726B2 (en) * | 2005-12-07 | 2012-01-17 | Microsoft Corporation | Implementing strong atomicity in software transactional memory |
US8056066B2 (en) * | 2007-08-22 | 2011-11-08 | International Business Machines Corporation | Method and apparatus for address taken refinement using control flow information |
US8478738B2 (en) * | 2007-12-10 | 2013-07-02 | International Business Machines Corporation | Object deallocation system and method |
KR20100091853A (en) * | 2009-02-11 | 2010-08-19 | 삼성전자주식회사 | Embedded system conducting a dynamic memory management and memory management method thereof |
US7685586B1 (en) | 2009-03-19 | 2010-03-23 | International Business Machines Corporation | Global escape analysis using instantiated type analysis |
US9329845B2 (en) * | 2009-06-04 | 2016-05-03 | Microsoft Technology Licensing, Llc | Determining target types for generic pointers in source code |
US9104577B2 (en) | 2013-08-27 | 2015-08-11 | International Business Machines Corporation | Optimizing memory bandwidth consumption using data splitting with software caching |
US9703537B2 (en) | 2015-11-02 | 2017-07-11 | International Business Machines Corporation | Method for defining alias sets |
US11301357B1 (en) * | 2019-09-26 | 2022-04-12 | Amazon Technologies, Inc. | Method to check application programming interface correctness in software |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
ATE233001T1 (en) * | 1992-06-15 | 2003-03-15 | Microsoft Corp | COMPUTER METHOD AND SYSTEM FOR MEMORY MANAGEMENT |
US5787447A (en) * | 1995-05-08 | 1998-07-28 | Sun Microsystems, Inc. | Memory allocation maintaining ordering across multiple heaps |
CA2166369C (en) * | 1995-12-29 | 2004-10-19 | Robert J. Blainey | Method and system for determining inter-compilation unit alias information |
US5900001A (en) * | 1997-04-23 | 1999-05-04 | Sun Microsystems, Inc. | Method and apparatus for optimizing exact garbage collection using a bifurcated data structure |
-
2000
- 2000-12-28 US US09/751,566 patent/US6457023B1/en not_active Expired - Lifetime
Cited By (57)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030023768A1 (en) * | 2001-07-24 | 2003-01-30 | Foti David A. | Designating an object for destruction |
US7237237B2 (en) * | 2001-07-24 | 2007-06-26 | The Mathworks, Inc. | Designating an object for destruction |
US20050015752A1 (en) * | 2003-07-15 | 2005-01-20 | International Business Machines Corporation | Static analysis based error reduction for software applications |
US8141064B2 (en) * | 2003-09-25 | 2012-03-20 | Lantronix, Inc. | Method and system for program transformation using flow-sensitive type constraint analysis |
US20090094588A1 (en) * | 2003-09-25 | 2009-04-09 | Lantronix, Inc. | Method and system for program transformation using flow-sensitive type constraint analysis |
US20050229044A1 (en) * | 2003-10-23 | 2005-10-13 | Microsoft Corporation | Predicate-based test coverage and generation |
US7584455B2 (en) * | 2003-10-23 | 2009-09-01 | Microsoft Corporation | Predicate-based test coverage and generation |
US8578389B1 (en) * | 2004-05-04 | 2013-11-05 | Oracle America, Inc. | Method and system for merging directed acyclic graphs representing data flow codes |
US20080313624A1 (en) * | 2004-10-01 | 2008-12-18 | Sony Computer Entertainment Inc. | Dynamic loading and unloading for processing unit |
US20070169124A1 (en) * | 2005-11-10 | 2007-07-19 | Aaron Kershenbaum | Method, system and program product for detecting and managing unwanted synchronization |
US20070174370A1 (en) * | 2006-01-12 | 2007-07-26 | Sun Microsystems, Inc. | Method and apparatus for decreasing object copying by a generational, copying garbage collector |
US7599973B2 (en) * | 2006-01-12 | 2009-10-06 | Sun Microsystems, Inc. | Method and apparatus for decreasing object copying by a generational, copying garbage collector |
US7954094B2 (en) * | 2006-03-27 | 2011-05-31 | International Business Machines Corporation | Method for improving performance of executable code |
US20070226698A1 (en) * | 2006-03-27 | 2007-09-27 | International Business Machines Corporation | Method for improving performance of executable code |
US9665970B2 (en) * | 2006-09-19 | 2017-05-30 | Imagination Technologies Limited | Variable-sized concurrent grouping for multiprocessing |
US20120133654A1 (en) * | 2006-09-19 | 2012-05-31 | Caustic Graphics Inc. | Variable-sized concurrent grouping for multiprocessing |
WO2008112422A1 (en) * | 2007-03-14 | 2008-09-18 | Nec Laboratories America, Inc. | System and method for scalable flow and context-sensitive pointer alias analysis |
US8930927B2 (en) * | 2007-06-04 | 2015-01-06 | International Business Machines Corporation | Diagnosing aliasing violations in a partial program view |
US20100162219A1 (en) * | 2007-06-04 | 2010-06-24 | International Business Machines Corporation | Diagnosing Aliasing Violations in a Partial Program View |
US8407676B2 (en) * | 2007-06-21 | 2013-03-26 | Nxp B.V. | Device and a method of managing a plurality of software items |
US20100175053A1 (en) * | 2007-06-21 | 2010-07-08 | Nxp B.V. | Device and a method of managing a plurality of software items |
CN102999328A (en) * | 2011-09-09 | 2013-03-27 | 微软公司 | Managing object lifetime in a cyclic graph |
WO2013036701A3 (en) * | 2011-09-09 | 2013-05-10 | Microsoft Corporation | Managing object lifetime in a cyclic graph |
WO2013036701A2 (en) | 2011-09-09 | 2013-03-14 | Microsoft Corporation | Managing object lifetime in a cyclic graph |
EP2754054A2 (en) * | 2011-09-09 | 2014-07-16 | Microsoft Corporation | Managing object lifetime in a cyclic graph |
JP2014529142A (en) * | 2011-09-09 | 2014-10-30 | マイクロソフト コーポレーション | Managing object life in a cyclic graph |
EP2754054A4 (en) * | 2011-09-09 | 2015-02-11 | Microsoft Corp | Managing object lifetime in a cyclic graph |
US9613073B2 (en) | 2011-09-09 | 2017-04-04 | Microsoft Technology Licensing, Llc | Managing object lifetime in a cyclic graph |
US9053017B2 (en) | 2011-09-09 | 2015-06-09 | Microsoft Technology Licensing, Llc | Managing object lifetime in a cyclic graph |
US9239780B2 (en) | 2011-12-21 | 2016-01-19 | Samsung Electronics Co., Ltd. | Selection of memory blocks for garbage collection based on variable block life threshold |
US8819382B2 (en) | 2012-08-09 | 2014-08-26 | Apple Inc. | Split heap garbage collection |
US9027006B2 (en) | 2012-08-09 | 2015-05-05 | Apple Inc. | Value profiling for code optimization |
US9256410B2 (en) | 2012-08-09 | 2016-02-09 | Apple Inc. | Failure profiling for continued code optimization |
US11016743B2 (en) | 2012-08-09 | 2021-05-25 | Apple Inc. | Runtime state based code re-optimization |
US9645923B1 (en) * | 2013-09-10 | 2017-05-09 | Google Inc. | Generational garbage collector on multiple heaps |
US20170139685A1 (en) * | 2014-06-25 | 2017-05-18 | Chengdu Puzhong Software Limted Company | Visual software modeling method to construct software views based on a software meta view |
US9519566B2 (en) * | 2015-04-15 | 2016-12-13 | International Business Machines Corporation | Modeling memory use of applications |
US9514025B2 (en) * | 2015-04-15 | 2016-12-06 | International Business Machines Corporation | Modeling memory use of applications |
US20170169212A1 (en) * | 2015-12-09 | 2017-06-15 | International Business Machines Corporation | Security enforcement in the presence of dynamic code loading |
US10296737B2 (en) * | 2015-12-09 | 2019-05-21 | International Business Machines Corporation | Security enforcement in the presence of dynamic code loading |
US20170185504A1 (en) * | 2015-12-23 | 2017-06-29 | Oracle International Corporation | Scalable points-to analysis via multiple slicing |
US11593249B2 (en) * | 2015-12-23 | 2023-02-28 | Oracle International Corporation | Scalable points-to analysis via multiple slicing |
US10296314B2 (en) * | 2016-11-01 | 2019-05-21 | Facebook, Inc. | Detecting and remedying memory leaks caused by object reference cycles |
US20180173728A1 (en) * | 2016-12-16 | 2018-06-21 | Fujitsu Limited | Information processing apparatus and method |
US9959194B1 (en) | 2017-03-08 | 2018-05-01 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of memory snapshots for replay responsiveness |
US10185645B2 (en) | 2017-03-08 | 2019-01-22 | Microsoft Technology Licensing, Llc | Resource lifetime analysis using a time-travel trace |
US10235273B2 (en) | 2017-03-08 | 2019-03-19 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of key frames for replay responsiveness |
US9983978B1 (en) | 2017-03-08 | 2018-05-29 | Microsoft Technology Licensing, Llc | Querying an indexed time-travel trace |
US9940369B1 (en) | 2017-03-08 | 2018-04-10 | Microsoft Technology Licensing, Llc | Searching an indexed time-travel trace |
US9934126B1 (en) | 2017-03-08 | 2018-04-03 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of reverse lookup data structures |
US9934127B1 (en) | 2017-03-08 | 2018-04-03 | Microsoft Technology Licensing, Llc | Indexing a trace by insertion of key frames for replay responsiveness |
US20180336120A1 (en) * | 2017-05-18 | 2018-11-22 | International Business Machines Corporation | Streams analysis tool and method |
US10235268B2 (en) * | 2017-05-18 | 2019-03-19 | International Business Machines Corporation | Streams analysis tool and method |
US10241893B2 (en) * | 2017-05-18 | 2019-03-26 | International Business Machines Corporation | Streams analysis tool and method |
US10635569B2 (en) | 2017-05-18 | 2020-04-28 | International Business Machines Corporation | Streams analysis tool and method |
US10282274B2 (en) | 2017-06-14 | 2019-05-07 | Microsoft Technology Licensing, Llc | Presenting differences between code entity invocations |
US11210071B2 (en) * | 2020-04-01 | 2021-12-28 | Microsoft Technology Licensing, Llc | Compiler sub expression directed acyclic graph (DAG) remat for register pressure |
Also Published As
Publication number | Publication date |
---|---|
US6457023B1 (en) | 2002-09-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6457023B1 (en) | Estimation of object lifetime using static analysis | |
US11016743B2 (en) | Runtime state based code re-optimization | |
Shaham et al. | Heap profiling for space-efficient Java | |
US6839725B2 (en) | Dynamic adaptive tenuring of objects | |
US6799191B2 (en) | Object sampling technique for runtime observations of representative instances thereof | |
Vivien et al. | Incrementalized pointer and escape analysis | |
US7167881B2 (en) | Method for heap memory management and computer system using the same method | |
Zorn | Comparative performance evaluation of garbage collection algorithms | |
US7367024B2 (en) | Compiler-driven dynamic memory allocation methodology for scratch-pad based embedded systems | |
Zorn | Barrier methods for garbage collection | |
Fink et al. | Unified analysis of array and object references in strongly typed languages | |
JP2006092532A (en) | Increasing data locality of recently accessed resource | |
US7210122B2 (en) | Method for reducing write barrier overhead | |
Qian et al. | Towards Dynamic Interprocedural Analysis in JVMs. | |
JP3826626B2 (en) | Program control apparatus, program control method, and program recording medium | |
US20090094301A1 (en) | Applications of overlooking root information for improving nondeferred reference-counting garbage collection | |
Duck et al. | An extended low fat allocator API and applications | |
Inoue et al. | Identifying the sources of cache misses in Java programs without relying on hardware counters | |
Jones et al. | A fast analysis for thread-local garbage collection with dynamic class loading | |
Higuera-Toledano et al. | Analyzing the performance of memory management in RTSJ | |
Acar et al. | Coupling memory and computation for locality management | |
US8103706B2 (en) | Nondeferred reference-counting garbage collection using overlooking roots | |
Zhang et al. | Online phase-adaptive data layout selection | |
Nilsen | Progress in hardware-assisted real-time garbage collection | |
Wimmer et al. | Automatic object colocation based on read barriers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PINTER, SHLOMIT;PORAT, SARA;REEL/FRAME:011424/0849 Effective date: 20001127 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
REMI | Maintenance fee reminder mailed | ||
FPAY | Fee payment |
Year of fee payment: 12 |
|
SULP | Surcharge for late payment |
Year of fee payment: 11 |
|
AS | Assignment |
Owner name: LINKEDIN CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:035201/0479 Effective date: 20140331 |