ACM Home Page
Please provide us with feedback. Feedback
Precise memory leak detection for java software using container profiling
Full text PdfPdf (566 KB)
Source
International Conference on Software Engineering archive
Proceedings of the 30th international conference on Software engineering table of contents
Leipzig, Germany
SESSION: Testing II table of contents
Pages 151-160  
Year of Publication: 2008
ISBN:978-1-60558-079-1
Authors
Guoqing Xu  Ohio State University, Columbus, OH, USA
Atanas Rountev  Ohio State University, Columbus, OH, USA
Sponsors
ACM: Association for Computing Machinery
SIGSOFT: ACM Special Interest Group on Software Engineering
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 22,   Downloads (12 Months): 257,   Citation Count: 1
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1368088.1368110
What is a DOI?

ABSTRACT

A memory leak in a Java program occurs when object references that are no longer needed are unnecessarily maintained. Such leaks are difficult to understand because static analyses typically cannot precisely identify these redundant references, and existing dynamic analyses for leak detection track and report fine-grained information about individual objects, producing results that are usually hard to interpret and lack precision.

We introduce a novel container-based heap-tracking technique, based on the observation that many memory leaks in Java programs occur due to containers that keep references to unused data entries. The novelty of the described work is two-fold: (1) instead of tracking arbitrary objects and finding leaks by analyzing references to unused objects, the technique tracks only containers and directly identifies the source of the leak, and (2) the approach computes a confidence value for each container based on a combination of its memory consumption and its elements' staleness (time since last retrieval), while previous approaches do not consider such combined metrics. Our experimental results show that the reports generated by the proposed technique can be very precise: for two bugs reported by Sun and for a known bug in SPECjbb, the top containers in the reports include the containers that leak memory.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

1
2
 
3
W. DePauw, D. Lorenz, J. Vlissides, and M. Wegman. Execution patterns in object-oriented visualization. In USENIX COOTS, pages 219--234, 1998.
 
4
W. DePauw and G. Sevitsky. Visualizing reference patterns for solving memory leaks in Java. Concurrency: Practice and Experience, 12(14):1431--1454, 2000.
 
5
6
 
7
R. Hastings and B. Joyce. Purify: A tool for detecting memory leaks and access errors in C and C++ programs. In Winter 1992 USENIX Conference, pages 125--138, 1992.
8
9
10
 
11
Jikes Research Virtual Machine. jikesrvm.org.
 
12
JProbe. www.quest.com/jprobe.
 
13
JProfiler. www.ej-technologies.com.
14
 
15
LeakHunter. www.wilytech.com/solutions/products.
 
16
N. Mitchell. The runtime structure of object ownership. In ECOOP, pages 74--98, 2006.
 
17
N. Mitchell and G. Sevitsky. Leakbot: An automated and lightweight tool for diagnosing memory leaks in large Java applications. In ECOOP, pages 351--377, 2003.
 
18
E. Nicholas. weblogs.java.net/blog/enicholas/archive/2006/04/leaking_evil.html.
 
19
M. Orlovich and R. Rugina. Memory leak analysis by contradiction. In SAS, pages 405--424, 2006.
 
20
 
21
 
22
SPECjbb2000 Documentation. www.spec.org.
 
23
Sun Bug Database. bugs.sun.com/bugdatabase.
 
24
25


Collaborative Colleagues:
Guoqing Xu: colleagues
Atanas Rountev: colleagues