Results 1 - 10
of
10
LeakSurvivor: Towards Safely Tolerating Memory Leaks for Garbage-Collected Languages
- In USENIX Annual Technical Conference
, 2008
"... Continuous memory leaks severely hurt program performance and software availability for garbage-collected programs. This paper presents a safe method, called LeakSurvivor, to tolerate continuous memory leaks at runtime for garbage-collected programs. Our main idea is to periodically swap out the “Po ..."
Abstract
-
Cited by 9 (2 self)
- Add to MetaCart
Continuous memory leaks severely hurt program performance and software availability for garbage-collected programs. This paper presents a safe method, called LeakSurvivor, to tolerate continuous memory leaks at runtime for garbage-collected programs. Our main idea is to periodically swap out the “Potentially Leaked ” (PL) memory objects identified by leak detectors from the virtual memory to disks. As a result, the virtual memory space occupied by the PL objects can be reclaimed by garbage collectors and available for future uses. If a swapped-out PL object is accesses later, LeakSurvivor will restore it from disks to the memory for correct program execution. Furthermore, LeakSurvivor helps developers to prune false positives. We have built the prototype of LeakSurvivor on top of Jikes RVM 2.4.2, a high performance Java-in-Java virtual machine developed by IBM. We conduct the experiments with three Java applications including Eclipse, SPECjbb2000 and Jigsaw. Among them, Eclipse and Jigsaw contain memory leaks introduced by their developers, while SPECjbb2000 contain a memory leak injected by us. Our results show that LeakSurvivor effectively tolerates memory leaks for two applications (Eclipse and SPECjbb2000), i.e., no cumulative performance degradation and no software failures when facing continuous memory leaks at runtime. For Jigsaw, LeakSurvivor extends the program lifetime by two times and improves the performance by 46 % compared with native runs. Furthermore, when there are no memory leaks, LeakSurvivor imposes small runtime overhead, i.e., 2.5 % over the leak detector and 23.7 % over the native runs. 1
Leak Pruning
- ASPLOS'09
, 2009
"... Managed languages improve programmer productivity with type safety and garbage collection, which eliminate memory errors such as dangling pointers, double frees, and buffer overflows. However, programs may still leak memory if programmers forget to eliminate the last reference to an object that will ..."
Abstract
-
Cited by 8 (4 self)
- Add to MetaCart
Managed languages improve programmer productivity with type safety and garbage collection, which eliminate memory errors such as dangling pointers, double frees, and buffer overflows. However, programs may still leak memory if programmers forget to eliminate the last reference to an object that will not be used again. Leaks slow programs by increasing collector workload and frequency. Growing leaks crash programs. Instead of crashing, leak pruning extends program availability by predicting and reclaiming leaked objects at run time. Whereas garbage collection over-approximates live objects using reachability, leak pruning predicts dead objects and reclaims them based on how stale they are and the size of stale data structures. Leak pruning preserves semantics because it waits for heap exhaustion before reclaiming objects and then poisons references to objects it reclaims. If the program later tries to access these objects, the virtual machine (VM) throws an internal error. We implement leak pruning in a Java VM, show its overhead is low, and evaluate it on 10 leaking programs. Leak pruning does not help two programs, executes four substantial programs 1.6-35X longer, and executes four programs, including two leaks in Eclipse, for at least 24 hours. In the worst case, leak pruning defers fatal errors. In the best case, programs with unbounded memory requirements execute indefinitely and correctly in bounded memory with consistent throughput.
Efficiently and precisely locating memory leaks and bloat
- Conference on Programming Language Design and Implementation
, 2009
"... Inefficient use of memory, including leaks and bloat, remain a significant challenge for C and C++ developers. Applications with these problems become slower over time as their working set grows and can become unresponsive. At the same time, memory leaks and bloat remain notoriously difficult to deb ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
Inefficient use of memory, including leaks and bloat, remain a significant challenge for C and C++ developers. Applications with these problems become slower over time as their working set grows and can become unresponsive. At the same time, memory leaks and bloat remain notoriously difficult to debug, and comprise a large number of reported bugs in mature applications. Previous tools for diagnosing memory inefficiencies—based on garbage collection, binary rewriting, or code sampling—impose high overheads (up to 100X) or generate many false alarms. This paper presents Hound, a runtime system that helps track down the sources of memory leaks and bloat in C and C++ applications. Hound employs data sampling, a staleness-tracking approach based on a novel heap organization, to make it both precise and efficient. Hound has no false positives, and its runtime and space overhead are low enough that it can be used in deployed applications. We demonstrate Hound’s efficacy across a suite of synthetic benchmarks and real applications.
Automatically Identifying Critical Input Regions and Code in Applications
"... Applications that process complex inputs often react in different ways to changes in different regions of the input. Small changes to forgiving regions induce correspondingly small changes in the behavior and output. Small changes to critical regions, on the other hand, can induce disproportionally ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
Applications that process complex inputs often react in different ways to changes in different regions of the input. Small changes to forgiving regions induce correspondingly small changes in the behavior and output. Small changes to critical regions, on the other hand, can induce disproportionally large changes in the behavior or output. Identifying the critical and forgiving regions in the input and the corresponding critical and forgiving regions of code is directly relevant to many software engineering tasks. We present a system, Snap, for automatically grouping related input bytes into fields and classifying each field and corresponding regions of code as critical or forgiving. Given an application and one or more inputs, Snap uses targeted input fuzzing in combination with dynamic execution and influence tracing to classify regions of input fields and code as critical or forgiving. Our experimental evaluation shows that Snap makes classifications with close to perfect precision (99%) and very good recall (between 99 % and 73%, depending on the application).
Plug: Automatically Tolerating Memory Leaks in C and C++ Applications
, 2008
"... Memory leaks remain a significant challenge for C and C++ developers. Leaky applications become slower over time as their working set grows, triggering paging, and can eventually become unresponsive. At the same time, memory leaks remain notoriously difficult to debug, and comprise a large number of ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Memory leaks remain a significant challenge for C and C++ developers. Leaky applications become slower over time as their working set grows, triggering paging, and can eventually become unresponsive. At the same time, memory leaks remain notoriously difficult to debug, and comprise a large number of reported bugs in mature applications. Existing approaches like conservative garbage collection can only remedy leaks of unreachable objects. In addition, they can impose unacceptable runtime or space overheads, or cause legal C/C++ applications to fail or retain excessive memory. This paper presents Plug, a runtime system for C/C++ applications that allows applications to deliver high performance in the face of both reachable and unreachable memory leaks. It uses a novel heap layout that isolates leaked objects from non-leaked objects, allowing them to be completely paged out to disk. Plug further reduces the space impact of leaks by employing virtual compaction, an approach that leverages virtual memory primitives to allow physical memory compaction without moving objects. We demonstrate Plug’s low overhead and its effectiveness at tolerating real memory leaks. 1.
Patterns and Statistical Analysis for Understanding Reduced Resource Computing
"... We present several general, broadly applicable mechanisms that enable computations to execute with reduced resources, typically at the cost of some loss in the accuracy of the result they produce. We identify several general computational patterns that interact well with these resource reduction mec ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
We present several general, broadly applicable mechanisms that enable computations to execute with reduced resources, typically at the cost of some loss in the accuracy of the result they produce. We identify several general computational patterns that interact well with these resource reduction mechanisms, present a concrete manifestation of these patterns in the form of simple model programs, perform simulationbased explorations of the quantitative consequences of applying these mechanisms to our model programs, and relate the model computations (and their interaction with the resource reduction mechanisms) to more complex benchmark applications drawn from a variety of fields.
Survival Strategies for Synthesized Hardware Systems
"... Abstract—Survival is a key concern of many complex systems. A standard approach to maximizing the likelihood of survival is to attempt to produce a system that is as free of errors as possible. We instead propose a methodology that changes the semantics of the underlying development and execution en ..."
Abstract
- Add to MetaCart
Abstract—Survival is a key concern of many complex systems. A standard approach to maximizing the likelihood of survival is to attempt to produce a system that is as free of errors as possible. We instead propose a methodology that changes the semantics of the underlying development and execution environments to cleanly and simply obtain survival guarantees that are difficult if not impossible to obtain with standard techniques. Examples of survival properties include continued execution in the face of addressing errors and guaranteed bounds on the amount of memory required during any execution of the system (even in the face of dynamic memory allocation). We summarize results for software implementations of these techniques and discuss issues and advantages that arise in the context of hardware implementations.
Integrated Reasoning and Proof Choice Point Selection in the Jahob System (Mechanisms for Program Survival)
"... Abstract. In recent years researchers have developed a wide range of powerful automated reasoning systems. We have leveraged these systems to build Jahob, a program specification, analysis, and verification system. In contrast to many such systems, which use a monolithic reasoning approach, Jahob pr ..."
Abstract
- Add to MetaCart
Abstract. In recent years researchers have developed a wide range of powerful automated reasoning systems. We have leveraged these systems to build Jahob, a program specification, analysis, and verification system. In contrast to many such systems, which use a monolithic reasoning approach, Jahob provides a general integrated reasoning framework, which enables multiple automated reasoning systems to work together to prove the desired program correctness properties. We have used Jahob to prove the full functional correctness of a collection of linked data structure implementations. The automated reasoning systems are able to automatically perform the vast majority of the reasoning steps required for this verification. But there are some complex verification conditions that they fail to prove. We have therefore developed a proof language, integrated into the underlying imperative Java programming language, that developers can use to control key choice points in the proof search space. Once the developer has resolved these choice points, the automated reasoning systems are able to complete the verification. This approach appropriately leverages both the developer’s insight into the high-level structure of the proof and the ability of the automated reasoning systems to perform the mechanical steps required to prove the verification conditions. Building on Jahob’s success with this challenging program verification problem, we contemplate the possibility of verifying the complete absence of fatal errors in large software systems. We envision combining simple techniques that analyze the vast majority of the program with heavyweight techniques that analyze those more sophisticated parts of the program that may require arbitrarily sophisticated reasoning. Modularity mechanisms such as abstract data types enable the sound division of the program for this purpose. The goal is not a completely correct program, but a program that can survive any remaining errors to continue to provide acceptable service. 1
Diagnosing and Tolerating Bugs in Deployed Systems Acknowledgments Diagnosing and Tolerating Bugs in Deployed Systems
, 2008
"... by ..."
www.cosy.sbg.ac.at Technical Report SeriesShort-term Memory for Self-collecting Mutators ⋆ Revised Version
, 2010
"... Abstract. We propose a new memory model for heap management, called short-term memory, and concurrent implementations of short-term memory for Java and C, called self-collecting mutators. In short-term memory objects on the heap expire after a nite amount of time, which makes deallocation unnecessar ..."
Abstract
- Add to MetaCart
Abstract. We propose a new memory model for heap management, called short-term memory, and concurrent implementations of short-term memory for Java and C, called self-collecting mutators. In short-term memory objects on the heap expire after a nite amount of time, which makes deallocation unnecessary. Self-collecting mutators requires programmer support to control the progress of time and thereby enable reclaiming the memory of expired objects. We informally describe a simple translation scheme for porting existing programs to self-collecting mutators. As shown by our experimental results on several benchmarks, self-collecting mutators performs competitively with garbage-collected and explicitly managed systems. Unlike garbage-collected systems, selfcollecting mutators does not introduce pause times and provides constant execution time of all operations, independent of the number of reachable objects, and constant short-term memory consumption after a steady state has been reached. Self-collecting mutators can be linked against any unmodi ed C code introducing a per-object space overhead of one word and negligible runtime overhead. Short-term memory may then be used to remove explicit deallocation of some but not necessarily all objects. 1

