ACM Home Page
Please provide us with feedback. Feedback
Destructors, finalizers, and synchronization
Full text PdfPdf (203 KB)
Source ACM SIGPLAN Notices archive
Volume 38 ,  Issue 1  (January 2003) table of contents
Pages: 262 - 272  
Year of Publication: 2003
ISSN:0362-1340
Also published in ...
Author
Hans-J. Boehm  Hewlett-Packard Laboratories, Palo Alto, CA
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 10,   Downloads (12 Months): 106,   Citation Count: 5
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/640128.604153
What is a DOI?

ABSTRACT

We compare two different facilities for running cleanup actions for objects that are about to reach the end of their life.Destructors, such as we find in C++, are invoked synchronously when an object goes out of scope. They make it easier to implement cleanup actions for objects of well-known lifetime, especially in the presence of exceptions.Languages like Java[8], Modula-3[12], and C\#[6] provide a different kind of "finalization" facility: Cleanup methods may be run when the garbage collector discovers a heap object to be otherwise inaccessible. Unlike C++ destructors, such methods run in a separate thread at some much less well-defined time.Languages like Java[8], Modula-3[12], and C\#[6] provide a different kind of "finalization" facility: Cleanup methods may be run when the garbage collector discovers a heap object to be otherwise inaccessible. Unlike C++ destructors, such methods run in a separate thread at some much less well-defined time.We argue that these are fundamentally different, and potentially complementary, language facilities. We also try to resolve some common misunderstandings about finalization in the process. In particular:

  • The asynchronous nature of finalizers is not just an accident of implementation or a shortcoming of tracing collectors; it is necessary for correctness of client code, fundamentally affects how finalizers must be written, and how finalization facilities should be presented to the user.
  • An object may legitimately be finalized while one of its methods are still running. This should and can be addressed by the language specification amd client code.


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
H.-J. Boehm. A garbage collector for C and C++. http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
 
3
 
4
G. Colvin, B. Dawes, P. Dimov, and D. Adler. Boost smart pointer library. http://www.boost.org/libs/smart_ptr/.
5
 
6
ECMA. Standard ECMA-334: C# Language Specification. ECMA, December 2001.
 
7
J. R. Ellis and D. L. Detlefs. Safe, efficient garbage collection for C++. Technical Report CSL-93-4, Xerox Palo Alto Research Center, September 1993.
 
8
 
9
 
10
J. Horning, B. Kalsow, P. McJones, and G. Nelson. Some useful modula-3 interfaces. Technical Report 113, Digital Systems Research Center, December 1993.
 
11
IEEE and The Open Group. IEEE Standard 1003.1-2001. IEEE, 2001.
 
12
 
13
P. Rovner. On adding garbage collection and runtime types to a strongly-typed, statically-checked, concurrent language. Technical Report CSL-84-7, Xerox Palo Alto Research Center, July 1985.
 
14
 
15
Sun Microsystems. Java 2 platform, standard edition, v 1.4.0 api specification. http://java.sun.com/j2se/1.4/docs/api/, 2002.
 
16
G. van Rossum. Python reference manual. http://www.python.org/doc/current/ref/ref.html.