Efficient Object Sampling Via Weak References
Total Page:16
File Type:pdf, Size:1020Kb
Efficient Object Sampling Via Weak References Ole Agesen£ Alex Garthwaite VMware Sun Microsystems Laboratories 3145 Porter Drive 1NetworkDrive Palo Alto, CA 94304 Burlington, MA 01803-0902 [email protected] [email protected] ABSTRACT from the burden of explicitly reasoning about the use of memory The performance of automatic memory management may be im- and eliminate two classes of errors: proved if the policies used in allocating and collecting objects had ¯ memory leaks errors where the application loses track of al- knowledge of the lifetimes of objects. To date, approaches to the located memory without freeing it. pretenuring of objects in older generations have relied on profile- driven feedback gathered from trace runs. This feedback has been ¯ dangling references where the application frees memory while used to specialize allocation sites in a program. These approaches retaining references to it and subsequently accesses this mem- suffer from a number of limitations. We propose an alternative that ory through these references. through efficient sampling of objects allows for on-line adaption of allocation sites to improve the efficiency of the memory system. In Garbage collectors work by handling all requests to allocate mem- doing so, we make use of a facility already present in many col- ory, by ensuring that this allocated memory has an appropriately lectors such as those found in JavaTM virtual machines: weak ref- typed format, and by guaranteeing that no memory is freed until it erences. By judiciously tracking a subset of allocated objects with is proven that the application holds no references to that memory. weak references, we are able to gather the necessary statistics to Garbage collection services typically allocate objects in a heap. make better object-placement decisions. Periodically, the collector locates the set of objects in the heap still reachable from the running program and frees the rest of the mem- ory in the heap so that it may be used for new allocation requests. 1. INTRODUCTION Often, the collection technique involves stopping the application With better knowledge of the behavior of objects in a running ap- while this process of finding the reachable objects is performed. plication, we can make better decisions about how to manage those For large heaps, this may lead to long pauses during which the ap- objects. These decisions may affect, for example, how and where plication is unable to proceed. objects are placed. Typically, instrumenting all objects to gather Generational collectors are designed to address part of this pause- this knowledge would slow the application too much to be practi- time problem. The observation is that recently allocated objects cal. We present a technique for dynamic sampling of a subset of tend to die (that is, become unreachable) quickly. The approach the allocated objects that incurs low runtime overheads. Coupled in generational collectors is to divide the heap into an ordered se- with automatic memory management or collection, this technique quence of two or more subheaps or generations. Objects are allo- allows us to improve the efficiency of the collector by segregating cated primarily in the first generation; as objects survive in a par- objects, sampled and non-sampled alike, based on observed charac- ticular generation across collections, that generation will have a teristics such as object lifetime. The sampling technique can track policy for promoting these longer-lived objects to the next genera- many kinds of information but for purposes of this paper we con- tion. Most collection work is performed in the youngest generation centrate on the improvement for generational garbage collectors. which is sized to cause most collection-time pauses to be of accept- ably short duration. 1.1 Improving Generational Collectors One inefficiency of a generational heap, however, is that long- Strongly typed languages like the JavaTM programming language lived objects may be copied many times before reaching the appro- rely on automatic memory management, also known as garbage priate generation. Our technique improves generational collectors collection. Memory management services free the programmer by identifying objects that will most likely survive to be tenured to a particular generation and by allocating such objects directly £ The work presented in this paper was performed while this author in that generation. By sampling a subset of the objects and study- was at Sun Microsystems, Inc. ing their lifetimes, we are able to better place objects to reduce the number of times such objects are copied within a generation or pro- moted between generations. A side-benefit is that by not allocating long-lived objects in younger generations, we reduce the number of collections in those generations. Finally, our approach uses con- tinued sampling to dynamically track how the observed lifetimes of objects change as the application executes. This allows the tech- nique to adapt as the application changes the way in which it uses objects. 1.2 Object Sampling and Fingerprinting ¯ the time at which the object is allocated. Allocation time may Central to our sampling technique is the use of weak references. be measured in many ways: real time, CPU time, number of Simply put, a weak reference is a reference to an object with the collections since the start of the application, number of bytes property that the garbage collector does not consider this reference allocated. If we combine information from allocation with when determining the reachability of the referred-to object. As long information gathered at other points in the program, we can as some other stronger reference keeps the object alive, the weak infer reasonable bounds on object lifetimes. reference will continue to refer to the object. At some point, the col- ¯ the allocation site in the program where the object is cre- lector determines that the object is only reachable from weak refer- ated. This may include a summary of information from one ences of a given strength. For each weak reference to the object, an or more frames of the calling context for the allocation op- “imminent death” action is then performed, followed by clearance eration. Many different places in a program may allocate of the weak reference so that the referred object can subsequently instances of the same class. Sometimes it might be use- be reclaimed. Weak references can be available as first-class con- ful to distinguish between these. For example, it might be TM structs in the language, as is the case with the Java platform, or that String objects allocated at one site (say, used for file they can be an implementation-level construct visible only to the names) tend to live much longer than String objects allo- runtime system. Either kind of weak reference may be used with cated at another site (say, created to print floating point num- our approach so long as the one chosen cannot cause an object to bers). become reachable again. The Java platform [10] mandates four kinds or strengths of weak ¯ the type of the object. In most object-oriented languages, this references under the package java.lang.ref: information does not need to be included in the fingerprint since it is stored in the object itself. For other languages ¯ soft references meant to be used for implementing caches where runtime type information is not readily available, it may be approximated by some other metric such as object ¯ weak references meant to implement canonicalization data structures size [3]. ¯ in object-oriented languages, the type of the receiver to which ¯ final references used to implement finalization the method performing the allocation is applied. 1 ¯ phantom references designed to schedule actions once an ob- ¯ an identifier for the thread performing the allocation. Objects ject ceases to be reachable of the same type allocated at the same allocation site by dif- Weak references to objects are processed in order of strength. Weak ferent threads may serve different purposes and, hence, have references, when processed, may be enqueued on a reference queue different lifespans. for further processing by the application. For our purposes, it is Weak references can be implemented relatively efficiently, and important to note that finalization of objects may result in those by varying the fraction of objects we sample, we can trade effi- objects becoming strongly reachable again. Only phantom refer- ciency and statistical accuracy against each other. Further, in envi- ences are guaranteed not to resuscitate a dying object. This means ronments like the Java platform where support for weak references that phantom references or VM-specific weak references are ap- already exists, we can efficiently gather statistics on sampled ob- propriate choices for implementing our proposal in a Java virtual jects as they become unreachable without having to explicitly ex- machine. amine the heap for dying objects after each collection. As a motivating example, suppose we want to determine the As can be seen, by including various pieces of information in the average lifespan of certain objects. Specifically, we might want fingerprints, and by controlling sampling rates, we can estimate: to know if instances of a certain class X tend to live longer than instances of a certain other class Y. Monitoring all allocations of ¯ how many objects are allocated of each type (class) classes X and Y to compute the exact lifespan statistics may be too costly to be practical in the production use of most programs. How- ¯ how many objects are allocated at each allocation site ever, it is possible that knowing the lifespans of a small fraction of ¯ how long each category (class, allocation site) of objects tend all X and Y instances, say one in every 1000 allocated, allows us to live to estimate lifespans for the entire population of X and Y instances with a useful degree of accuracy.