ACM Home Page
Please provide us with feedback. Feedback
Safe manual memory management
Full text PdfPdf (272 KB)
Source
International Symposium on Memory Management archive
Proceedings of the 6th international symposium on Memory management table of contents
Montreal, Quebec, Canada
SESSION: Explicit memory management table of contents
Pages: 2 - 14  
Year of Publication: 2007
ISBN:978-1-59593-893-0
Authors
David Gay  Intel, Berkeley, CA
Rob Ennals  Intel, Berkeley, CA
Eric Brewer  Intel, Berkeley, CA
Sponsors
ACM: Association for Computing Machinery
SIGPLAN: ACM Special Interest Group on Programming Languages
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 10,   Downloads (12 Months): 128,   Citation Count: 1
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1296907.1296911
What is a DOI?

ABSTRACT

We present HeapSafe, a tool that uses reference counting to dynamically verify the soundness of manual memory management of C programs. HeapSafe relies on asimple extension to the usual malloc/free memory management API: delayed free scopes during which otherwise dangling references can exist. Porting programs for use with HeapSafe typically requires little effort (on average 0.6% oflines change), adds an average 11% time overhead (84% in the worst case), and increases space usage by an average of 13%. These results are based on portingover half a million lines of C code, including perl where we found sixpreviously unknown bugs.Many existing C programs continue to use unchecked manual memorymanagement. One reason is that programmers fear that moving to garbage collection is too big a risk. We believe that HeapSafe is a practical way toprovide safe memory management for such programs. Since HeapSafe checks existing memory management rather than changing it, programmers need not worrythat HeapSafe will introduce new bugs; and, since HeapSafe does not managememory itself, programmers can choose to deploy their programs without HeapSafe if performance is critical (a simple header file allows HeapSafe programs to compile and run with a regular C compiler). In contrast, we foundthat garbage collection, although faster, had much higher space overhead, and occasionally caused a space-usage explosion that made the program unusable.


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
APPLE. Cocoa. http://developer.apple.com.
3
 
4
 
5
6
 
7
 
8
CONDIT, J., HARREN, M., ANDERSON, Z., GAY, D., AND NECULA, G. Dependent types for low--level programming. In ESOP-07.
9
10
11
12
13
 
14
15
 
16
 
17
JONES, R., AND LINS, R. Garbage Collection. Wiley, 1996.
 
18
JONES, R. W. M., AND KELLY, P. H. J. Backwards compatible bounds checking for arrays and pointers in C. In Automated and Algorithmic Debugging (AADEBUG--97) (1997).
19
 
20
 
21
LOMET, D. B. Making pointers safe in system programming languages. IEEE Transactions on Software Engineering SE-- 11, 1 (Jan. 1985), 87--96.
22
 
23
 
24
NEXT. Openstep. http://www.gnustep.org.
 
25
 
26
PERENS, B. Electric fence. http://perens.com/FreeSoftware/.
 
27
RATIONAL SOFTWARE. Purify: Fast detection of memory leaks and access errors. http://www.rational.com.
28
 
29
 
30
SPEC. SPECCPU 2000 and 2006. http://www.spec.org.
 
31
WATSON, G. Dmalloc -- debug malloc. http://dmalloc.com.
 
32
 
33
ZORN, B. The measured cost of conservative garbage collection. Tech. Rep. CU--CS--573--92, University of Colorado at Boulder, April 1992.


Collaborative Colleagues:
David Gay: colleagues
Rob Ennals: colleagues
Eric Brewer: colleagues