Heap profiling for space efficiency

Runciman, Colin; Röjemo, Niklas

doi:10.1007/3-540-61628-4_6

Cited by 9 publications

(7 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such results point to the usefulness of the work being carried out by Runciman and Rojemo on the retainer profiler [Runciman and Rojemo, 1996], section 2.6.2. …”

Section: Discussionmentioning

confidence: 67%

“…Runciman and Rojemo were also able to identify this part of the program as expensive with their retainer heap profiler [Runciman and Rojemo, 1996]. The fix which they proposed to reduce the heap space used during program execution is used in this context to reduce the time taken during program execution.…”

Section: Costmentioning

confidence: 99%

“…• The resource usage is recorded by the execution sampling method, nhc heap profiler nhc (nearly a /iaskell compiler) [Runciman and Rojemo, 1996] is a subset of Haskell written for a machine with a small amount of memory (less than 4Mb The 'cost-centre' profiler Peyton Jones, 1994,1995] specifically addresses the problem of attributing data gathered during the program's execution back to the source code. Distributed with the Glasgow Haskell Compiler Peyton Jones, Hall and Hammond, 1993] the profiler offers occurrence counts, timed and heap profiling, including serial profiling of time and memory usage.…”

Section: Heap Profiling 1992mentioning

confidence: 99%

See 2 more Smart Citations

Profiling large-scale lazy functional programs

Morgan

Jarvis

1998

J. Funct. Prog.

View full text Add to dashboard Cite

How to cite:Jarvis, Stephen Andrew (1996) Pro ling large-scale lazy functional programs, Durham theses, Durham University. Available at Durham E-Theses Online: http://etheses.dur.ac.uk/5307/ Use policy The full-text may be used and/or reproduced, and given to third parties in any format or medium, without prior permission or charge, for personal research or study, educational, or not-for-pro t purposes provided that:• a full bibliographic reference is made to the original source• a link is made to the metadata record in Durham E-Theses• the full-text is not changed in any way The full-text must not be sold in any format or medium without the formal permission of the copyright holders. The copyright of this thesis rests with the author. No quotation from it should be published without the written consent of the author and information derived from it should be acknowledged. AbstractThe LOLITA natural language processing system is an example of one of the ever increasing number of large-scale systems written entirely in a functional programming language. The system consists of over 50,000 lines of Haskell code and is able to perform a number of tasks such as semantic and pragmatic analysis of text, context scanning and query analysis. Such a system is more useful if the results are calculated in real-time, therefore the efficiency of such a system is paramount. For the past three years we have used profiling tools supplied with the Haskell compilers GHC and HBC to analyse and reason about our programming solutions and have achieved good results; however, our experience has shown that the profiling life-cycle is often too long to make a detailed analysis of a large system possible, and the profiling results are often misleading.A profiling system is developed which allows three types of functionality not previously found in a profiler for lazy functional programs. Firstly, the profiler is able to produce results based on an accurate method of cost inheritance. We have found that this reduces the possibility of the programmer obtaining misleading profiling results. Secondly, the programmer is able to explore the results after the execution of the program. This is done by selecting and deselecting parts of the program using a post-processor. This greatly reduces the analysis time as no further compilation, execution or profiling of the program is needed. Finally, the new profiling system allows the user to examine aspects of the run-time call structure of the program. This is useful in the analysis of the run-time behaviour of the program.Previous attempts at extending the results produced by a profiler in such a way have failed due to the exceptionally high overheads. Exploration of the overheads produced by the new profiling scheme show that typical overheads in profiling the LOLITA system are: a 10% increase in compilation time; a 7% increase in executable size and a 70% run-time overhead. These overheads mean a considerable saving in time in the detailed analysis of profiling a large, lazy functional program. ...

show abstract

“…Such results point to the usefulness of the work being carried out by Runciman and Rojemo on the retainer profiler [Runciman and Rojemo, 1996], section 2.6.2. …”

Section: Discussionmentioning

confidence: 67%

Section: Costmentioning

confidence: 99%

Section: Heap Profiling 1992mentioning

confidence: 99%

See 1 more Smart Citation

Profiling large-scale lazy functional programs

Morgan

Jarvis

1998

J. Funct. Prog.

View full text Add to dashboard Cite

show abstract

“…For garbage-collected languages that lack user-defined class information, such as Standard ML, other mechanisms may be able to provide equivalent information. Previous work provides some suggestions for functional languages that tag objects [32,33,34]. For example, type-specific tags could be used to index into a hashmap for storing class nodes.…”

Section: Cork In Other Languagesmentioning

confidence: 99%

Detecting memory leaks in managed languages with Cork

Jump

McKinley

2009

Softw Pract Exp

View full text Add to dashboard Cite

SUMMARYA memory leak in a managed program occurs when the program inadvertently maintains references to objects that it no longer needs. Memory leaks cause systematic heap growth which degrades performance and results 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 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.

show abstract

“…Previous work for provide some suggestions for functional languages that tag objects [21,22,23]. We exploit the object model of polymorphically typed languages (such as Java and C#) by piggybacking on their required global type information to keep space overheads to a minimum.…”

Section: Cork In Other Languagesmentioning

confidence: 99%

Cork

Jump

McKinley

2007

Proceedings of the 34th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

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 TPFGs 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 Eclipse, something their developers had not previously done. Cork is accurate, scalable, and efficient enough to consider using online.

show abstract

Heap profiling for space efficiency

Cited by 9 publications

References 7 publications

Profiling large-scale lazy functional programs

Profiling large-scale lazy functional programs

Detecting memory leaks in managed languages with Cork

Cork

Contact Info

Product

Resources

About