Heap Growth Research Articles

BLeak

Memory leaks in web applications are pervasive and difficult to debug. Leaks degrade responsiveness by increasing garbage collection costs and can even lead to browser tab crashes. Previous leak detection approaches designed for conventional applications are ineffective in the browser environment. Tracking down leaks currently requires intensive manual effort by web developers, which is often unsuccessful. This paper introduces BLEAK (Browser Leak debugger), the first system for automatically debugging memory leaks in web applications. BLEAK'S algorithms leverage the observation that in modern web applications, users often repeatedly return to the same (approximate) visual state (e.g., the inbox view in Gmail). Sustained growth between round trips is a strong indicator of a memory leak. To use BLEAK, a developer writes a short script (17-73 LOC on our benchmarks) to drive a web application in round trips to the same visual state. BLEAK then automatically generates a list of leaks found along with their root causes, ranked by return on investment. Guided by BLEAK, we identify and fix over 50 memory leaks in popular libraries and apps including Airbnb, AngularJS, Google Analytics, Google Maps SDK, and jQuery. BLEAK'S median precision is 100%; fixing the leaks it identifies reduces heap growth by an average of 94%, saving from 0.5MB to 8MB per round trip.

Granular surface flow on an asymmetric conical heap

We carry out an experimental study of the granular surface flow of nearly monodisperse glass beads on a conical heap formed on a rough circular disc by a narrow stream of the particles from a hopper, with the pouring point displaced from the centre of the disc. During the growth phase, an axisymmetric heap is formed, which grows either by periodic avalanches or by non-periodic avalanches that occur randomly over the azimuthal location of the heap, depending on the operating conditions and system properties. The dynamics of heap growth is characterized by the variation of the heap height, angle of repose and the angular velocity of the periodic avalanche with time, for different mass flow rates from the hopper. When the base of the heap reaches the edge of the disc closest to the pouring point, the heap stops growing and a steady surface flow of particles is developed on the heap surface, with particles flowing over the edge of the disc into a collection tray. The geometry is a unique example of a granular flow on an erodible bed without any bounding side walls. The corresponding steady state geometry of the asymmetric heap is characterized by means of surface contours and angles of repose. The streamwise and transverse surface velocities are measured using high-speed video photography and image analysis for different mass flow rates. The flowing layer thickness is measured by immersing a coated needle in the flow at different positions on the mid-line of the flow. The surface angle of the flowing layer is found to be significantly smaller than the angle of repose and to be independent of the mass flow rate. The velocity profiles at different streamwise positions for different mass flow rates are found to be geometrically similar and are well described by Gaussian functions. The flowing layer thickness is calculated from a model using the measured surface velocities. The predicted values match the measured values quite well.

BLeak: automatically debugging memory leaks in web applications

Despite the presence of garbage collection in managed languages like JavaScript, memory leaks remain a serious problem. In the context of web applications, these leaks are especially pervasive and difficult to debug. Web application memory leaks can take many forms, including failing to dispose of unneeded event listeners, repeatedly injecting iframes and CSS files, and failing to call cleanup routines in third-party libraries. Leaks degrade responsiveness by increasing GC frequency and overhead, and can even lead to browser tab crashes by exhausting available memory. Because previous leak detection approaches designed for conventional C, C++ or Java applications are ineffective in the browser environment, tracking down leaks currently requires intensive manual effort by web developers. This paper introduces BLeak (Browser Leak debugger), the first system for automatically debugging memory leaks in web applications. BLeak's algorithms leverage the observation that in modern web applications, users often repeatedly return to the same (approximate) visual state (e.g., the inbox view in Gmail). Sustained growth between round trips is a strong indicator of a memory leak. To use BLeak, a developer writes a short script (17-73 LOC on our benchmarks) to drive a web application in round trips to the same visual state. BLeak then automatically generates a list of leaks found along with their root causes, ranked by return on investment. Guided by BLeak, we identify and fix over 50 memory leaks in popular libraries and apps including Airbnb, AngularJS, Google Analytics, Google Maps SDK, and jQuery. BLeak's median precision is 100%; fixing the leaks it identifies reduces heap growth by an average of 94%, saving from 0.5 MB to 8 MB per round trip. We believe BLeak's approach to be broadly applicable beyond web applications, including to GUI applications on desktop and mobile platforms.

Mark without much Sweep Algorithm for Garbage Collection

In this paper two simple improvements over traditional mark-sweep collector are proposed. The core idea is placing small objects of the same type in buckets. The buckets are organised in such way to eliminate the internal fragmentation, sweeping, and freeing inside them. The measured improvement of garbage collection time over traditional mark-sweep is 19%. Another proposed improvement is more general and is applicable to other garbage collection algorithms as well. It uses heuristics to control the heap growth. The regularities in behaviour of objects of particular types are used to determine whether the collection should be performed or avoided in favour of immediate heap expansion. The heap expansion algorithm reduces garbage collection time over traditional mark-sweep for 49% while keeping the heap size approximately the same.

The economics of garbage collection

This paper argues that economic theory can improve our understanding of memory management. We introduce the allocation curve , as an analogue of the demand curve from microeconomics. An allocation curve for a program characterises how the amount of garbage collection activity required during its execution varies in relation to the heap size associated with that program. The standard treatment of microeconomic demand curves (shifts and elasticity) can be applied directly and intuitively to our new allocation curves. As an application of this new theory, we show how allocation elasticity can be used to control the heap growth rate for variable sized heaps in Jikes RVM.

An experimental study of mounds formed by dumping coarse sediment in channel flow

The development of large sediment mounds formed by continuous release of coarse materials in flowing water is reported. Growths of mound height, longitudinal profile and areal extent were examined for three flow conditions. Longitudinal profiles of depositions during the development phase of the mounds were approximately similar, and they can be expressed by an exponential function if scaled with the maximum height and a width parameter. From observations, it appeared that the mound peak shifted gradually towards upstream and followed the outer part of the sediment plume. The heap growth can be expressed as a function of buoyancy flux due to sediment disposal, flow momentum and densimetric particle Froude number. The deposition height increased with normalized time until reaching close to the water surface. The width and area developed faster with normalized time than the height. The deposition area with coarse sediment was characterized by a downstream tail and fin-like extensions on the sides which differed from observations in previous experiments with fine sand.

Detecting memory leaks in managed languages with Cork

AbstractA memory leak in a managed language occurs when the program inadvertently maintains references to objects that it no longer needs. Memory leaks cause systematic heap growth that degrade performance and can result in program crashes after perhaps days or weeks of execution. Prior approaches for detecting memory leaks rely on heap differencing or detailed object statistics which store state proportional to the number of objects in the heap. These overheads preclude their use on the same processor for deployed long‐running applications. This paper introduces Cork as a tool that accurately identifies heap growth caused by leaks. It is space efficient (adding less than 1% to the heap) and time efficient (adding 2.3% on average to total execution time). We implement this approach of examining and summarizing the class of live objects during garbage collection in a class points‐from graph (CPFG). Each node in the CPFG represents a class and edges between nodes represent references between objects of the specific classes. Cork annotates nodes and edges with the corresponding volume of live objects. Cork identifies growing data structures across multiple collections and computes a class slice to identify leaks for the user. We experiment with two functions for identifying growth and show that Cork is accurate: it identifies systematic heap growth with no false positives in 4 of 15 benchmarks we tested. Cork's slice report enabled us to quickly identify and eliminate growing data structures in large and unfamiliar programs, something their developers had not previously done. Copyright © 2009 John Wiley & Sons, Ltd.

Cork

A memory leak in a garbage-collected program occurs when the program inadvertently maintains references to objects that it no longer needs. Memory leaks cause systematic heap growth, degrading performance and resulting in program crashes after perhaps days or weeks of execution. Prior approaches for detecting memory leaks rely on heap differencing or detailed object statistics which store state proportional to the number of objects in the heap. These overheads preclude their use on the same processor for deployed long-running applications.This paper introduces a dynamic heap-summarization technique based on type that accurately identifies leaks, is space efficient (adding less than 1% to the heap), and is time efficient (adding 2.3% on average to total execution time). We implement this approach in Cork which utilizes dynamic type information and garbage collection to summarize the live objects in a type points-from graph ( TPFG ) whose nodes (types) and edges (references between types) are annotated with volume. Cork compares TPFG s across multiple collections, identifies growing data structures, and computes a type slice for the user. Cork is accurate: it identifies systematic heap growth with no false positives in 4 of 15 benchmarks we tested. Cork's slice report enabled us (non-experts) to quickly eliminate growing data structures in SPECjbb2000 and Elipse, something their developers had not previously done. Cork is accurate, scalable, and efficient enough to consider using online.

Controlling garbage collection and heap growth to reduce the execution time of Java applications

In systems that support garbage collection, a tension exists between collecting garbage too frequently and not collecting it frequently enough. Garbage collection that occurs too frequently may introduce unnecessary overheads at the risk of not collecting much garbage during each cycle. On the other hand, collecting garbage too infrequently can result in applications that execute with a large amount of virtual memory (i.e., with a large footprint) and suffer from increased execution times due to paging.In this article, we use a large set of Java applications and the highly tuned and widely used Boehm-Demers-Weiser (BDW) conservative mark-and-sweep garbage collector to experimentally examine the extent to which the frequency of garbage collection impacts an application's execution time, footprint, and pause times. We use these results to devise some guidelines for controlling garbage collection and heap growth in a conservative garbage collector in order to minimize application execution times. Then we describe new strategies for controlling garbage collection and heap growth that impact not only the frequency with which garbage collection occurs but also the points at which it occurs. Experimental results demonstrate that when compared with the existing approach used in the standard BDW collector, our new strategy can significantly reduce application execution times.Our goal is to obtain a better understanding of how to control garbage collection and heap growth for an individual application executing in isolation. These results can be applied in a number of high-performance computing and server environments, in addition to some single-user environments. This work should also provide insights into how to make better decisions that impact garbage collection in multiprogrammed environments.

Asymptotic behavior of random heaps

We consider a random walk Wn on the locally free group (or equivalently a signed random heap) with m generators subject to periodic boundary conditions. Let #T(Wn) denote the number of removable elements, which determines the heap's growth rate. We prove that limn→∞𝔼(#T(Wn))/m ≤ 0.32893 for m ≥ 4. This result disproves a conjecture (due to Vershik, Nechaev and Bikbov [Comm Math Phys 212 (2000), 469–501]) that the limit tends to 1/3 as m → ∞. © 2005 Wiley Periodicals, Inc. Random Struct. Alg., 2005

Software prefetching for mark-sweep garbage collection

Tracing garbage collectors traverse references from live program variables, transitively tracing out the closure of live objects. Memory accesses incurred during tracing are essentially random: a given object may contain references to any other object. Since application heaps are typically much larger than hardware caches, tracing results in many cache misses. Technology trends will make cache misses more important, so tracing is a prime target for prefetching.Simulation of Java benchmarks running with the Boehm-De-mers-Weiser mark-sweep garbage collector for a projected hardware platform reveal high tracing overhead (up to 65% of elapsed time), and that cache misses are a problem. Applying Boehm's default prefetching strategy yields improvements in execution time (16% on average with incremental/generational collection for GC-intensive benchmarks), but analysis shows that his strategy suffers from significant timing problems: prefetches that occur too early or too late relative to their matching loads. This analysis drives development of a new prefetching strategy that yields up to three times the performance improvement of Boehm's strategy for GC-intensive benchmark (27% average speedup), and achieves performance close to that of perfect timing ie , few misses for tracing accesses) on some benchmarks. Validating these simulation results with live runs on current hardware produces average speedup of 6% for the new strategy on GC-intensive benchmarks with a GC configuration that tightly controls heap growth. In contrast, Boehm's default prefetching strategy is ineffective on this platform.

Software prefetching for mark-sweep garbage collection

Tracing garbage collectors traverse references from live program variables, transitively tracing out the closure of live objects. Memory accesses incurred during tracing are essentially random: a given object may contain references to any other object. Since application heaps are typically much larger than hardware caches, tracing results in many cache misses. Technology trends will make cache misses more important, so tracing is a prime target for prefetching.Simulation of Java benchmarks running with the Boehm-De-mers-Weiser mark-sweep garbage collector for a projected hardware platform reveal high tracing overhead (up to 65% of elapsed time), and that cache misses are a problem. Applying Boehm's default prefetching strategy yields improvements in execution time (16% on average with incremental/generational collection for GC-intensive benchmarks), but analysis shows that his strategy suffers from significant timing problems: prefetches that occur too early or too late relative to their matching loads. This analysis drives development of a new prefetching strategy that yields up to three times the performance improvement of Boehm's strategy for GC-intensive benchmark (27% average speedup), and achieves performance close to that of perfect timing ie , few misses for tracing accesses) on some benchmarks. Validating these simulation results with live runs on current hardware produces average speedup of 6% for the new strategy on GC-intensive benchmarks with a GC configuration that tightly controls heap growth. In contrast, Boehm's default prefetching strategy is ineffective on this platform.

Software prefetching for mark-sweep garbage collection

Tracing garbage collectors traverse references from live program variables, transitively tracing out the closure of live objects. Memory accesses incurred during tracing are essentially random: a given object may contain references to any other object. Since application heaps are typically much larger than hardware caches, tracing results in many cache misses. Technology trends will make cache misses more important, so tracing is a prime target for prefetching.Simulation of Java benchmarks running with the Boehm-De-mers-Weiser mark-sweep garbage collector for a projected hardware platform reveal high tracing overhead (up to 65% of elapsed time), and that cache misses are a problem. Applying Boehm's default prefetching strategy yields improvements in execution time (16% on average with incremental/generational collection for GC-intensive benchmarks), but analysis shows that his strategy suffers from significant timing problems: prefetches that occur too early or too late relative to their matching loads. This analysis drives development of a new prefetching strategy that yields up to three times the performance improvement of Boehm's strategy for GC-intensive benchmark (27% average speedup), and achieves performance close to that of perfect timing ie , few misses for tracing accesses) on some benchmarks. Validating these simulation results with live runs on current hardware produces average speedup of 6% for the new strategy on GC-intensive benchmarks with a GC configuration that tightly controls heap growth. In contrast, Boehm's default prefetching strategy is ineffective on this platform.

Controlling garbage collection and heap growth to reduce the execution time of Java applications

In systems that support garbage collection, a tension exists between collecting garbage too frequently and not collecting garbage frequently enough. Garbage collection that occurs too frequently may introduce unnecessary overheads at the rist of not collecting much garbage during each cycle. On the other hand, collecting garbage too infrequently can result in applications that execute with a large amount of virtual memory (i.e., with a large footprint) and suffer from increased execution times die to paging. In this paper, we use a large colleciton of Java applications and the highly tuned and widely used Boehm-Demers-Weiser (BDW) conservative mark-and-sweep garbage collector to experimentally examine the extent to which the frequency of garbage collectio impacts an application's execution time, footprint, and pause times. We use these results to devise some guidelines for controlling garbage and heap growth in a conservative garbage collection in order to minimize application execution times. Then we describe new strategies for controlling in order to minimize application execution times.

Java server performance: A case study of building efficient, scalable Jvms

The importance of the JavaTM platform has shifted from a client-centered paradigm to the server. In particular, the Java language has matured into a viable programming model for server applications. Correspondingly, the requirements on the Java virtual machine (Jvm) have shifted. This paper details the serverspecific performance enhancements made to the core Jvm and just-in-time (JIT) compiler, which have allowed the IBM Developer Kits that implement Java code for Intel processors to become industry performance leaders. The paper focuses on synchronization implementation and granularity improvements that have greatly increased the scalability of the Java language on multiprocessor machines. Focus is also given to memory management, specifically, object allocation, garbage collection, and heap management. Details of communication and connection scaling are also provided. Finally, server-specific enhancements to the JIT compiler are discussed. All component enhancements in the paper are explained, and their performance implications are quantified with results from representative multithreaded server workloads. The paper summarizes work from across IBM. The authors' specific contributions include the three-tier spin lock, the thread local heap and freelist merge, the dynamic heap growth algorithm, bitwise sweep, compaction avoidance, and the suite of network enhancements.