ACM Home Page
Please provide us with feedback. Feedback
Tolerating memory leaks
Full text PdfPdf (1.11 MB)
Source
Conference on Object Oriented Programming Systems Languages and Applications archive
Proceedings of the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications table of contents
Nashville, TN, USA
SESSION: Runtime table of contents
Pages 109-126  
Year of Publication: 2008
ISBN:978-1-60558-215-3
Also published in ...
Authors
Michael D. Bond  University of Texas at Austin, Austin, TX, USA
Kathryn S. McKinley  University of Texas at Austin, Austin, TX, USA
Sponsors
SIGPLAN: ACM Special Interest Group on Programming Languages
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 30,   Downloads (12 Months): 261,   Citation Count: 4
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

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

ABSTRACT

Type safety and garbage collection in managed languages eliminate memory errors such as dangling pointers, double frees, and leaks of unreachable objects. Unfortunately, a program still leaks memory if it maintains references to objects it will never use again. Leaked objects decrease program locality and increase garbage collection frequency and workload. A growing leak will eventually exhaust memory and crash the program.

This paper introduces a leak tolerance approach called Melt that safely eliminates performance degradations and crashes due to leaks of dead but reachable objects in managed languages, given sufficient disk space to hold leaking objects. Melt (1) identifies stale objects that the program is not accessing; (2) segregates in-use and stale objects by storing stale objects to disk; and (3) preserves safety by activating stale objects if the program subsequently accesses them. We design and build a prototype implementation of Melt in a Java VM and show it adds overhead low enough for production systems. Whereas existing VMs grind to a halt and then crash on programs with leaks, Melt keeps many of these programs running much longer without significantly degrading performance. Melt provides users the illusion of a fixed leak and gives developers more time to fix leaky programs.


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
4
5
 
6
7
8
9
 
10
M. D. Bond and K. S. McKinley. Tolerating Memory Leaks. Technical Report TR-07-64, University of Texas at Austin, December 2007.
 
11
D. Breitgand, M. Goldstein, E. Henis, O. Shehory, and Y. Weinsberg. PANACEA-Towards a Self-Healing Development Framework. In Integrated Network Management, pages 169--178, 2007.
12
13
14
15
 
16
DaCapo Benchmark Regression Tests. http://jikesrvm.anu.-edu.au/?dacapo/.
17
 
18
Eclipse.org Home. http://www.eclipse.org/.
 
19
B. Goetz. Plugging memory leaks with weak references, 2005. http://www-128.ibm.com/developerworks/java/-library/j-jtp11225/.
 
20
B. Goetz. Plugging memory leaks with soft references, 2006. http://www-128.ibm.com/developerworks/java/-library/j-jtp01246.html.
21
 
22
 
23
S. C. Gupta and R. Palanki. Java memory leaks -- Catch me if you can, 2005. http://www.ibm.com/developerworks/-rational/library/05/0816 GuptaPalanki/index.html.
 
24
R. Hastings and B. Joyce. Purify: Fast Detection of Memory Leaks and Access Errors. In Winter USENIX Conference, pages 125--136, 1992.
25
26
27
 
28
29
 
30
31
 
32
Jikes RVM. http://www.jikesrvm.org.
 
33
Jikes RVM Research Archive. http://www.jikesrvm.org/-Research+Archive.
34
 
35
J.Maebe, M. Ronsse, and K. D. Bosschere. Precise Detection of Memory Leaks. In International Workshop on Dynamic Analysis, pages 25--31, 2004.
 
36
 
37
Mckoi SQL Database message board: memory/thread leak with Mckoi 0.93 in embedded mode, 2002. http://www.-mckoi.com/database/mail/subject.jsp?id=2172.
 
38
N. Mitchell and G. Sevitsky. LeakBot: An Automated and Lightweight Tool for Diagnosing Memory Leaks in Large Java Applications. In European Conference on Object-Oriented Programming, pages 351--377, 2003.
 
39
40
41
 
42
G. Novark, E. D. Berger, and B. G. Zorn. Plug: Automatically Tolerating Memory Leaks in C and C++ Applications. Technical Report UM-CS-2008-009, University of Massachusetts, 2008.
43
 
44
Oracle. JRockit Mission Control. http://www.oracle.com/-technology/products/jrockit/missioncontrol/.
45
 
46
D. Plainfossé. Distributed Garbage Collection and Reference Management in the Soul Object Support System. PhD thesis, Université Paris-6, Pierre-et-Marie-Curie, 1994.
 
47
48
 
49
Quest. JProbe Memory Debugger. http://www.quest.com/-jprobe/debugger.asp.
 
50
51
 
52
SciTech Software. .NET Memory Profiler. http://www.-scitech.se/memprofiler/.
 
53
Standard Performance Evaluation Corporation. SPECjvm98 Documentation, release 1.03 edition, 1999.
 
54
Standard Performance Evaluation Corporation. SPECjbb2000 Documentation, release 1.01 edition, 2001.
 
55
Sun Developer Network Forum. Java Programming {Archive} - garbage collection dilema (sic), 2003. http://forum.java.-sun.com/thread.jspa?threadID=446934.
 
56
Sun Developer Network Forum. Reflections & Reference Objects - Java memory leak example, 2003. http://forum.-java.sun.com/thread.jspa?threadID=456545.
 
57
58
59
 
60
61
 
62
 
63
B. Zorn. Barrier Methods for Garbage Collection. Technical Report CU-CS-494-90, University of Colorado at Boulder, 1990.


Collaborative Colleagues:
Michael D. Bond: colleagues
Kathryn S. McKinley: colleagues