TL;DR: In this paper, a postmortem finalization mechanism for garbage collection is proposed, which delays the execution of the finalization actions until the object in question has been fully reclaimed by the system's garbage collector.
Abstract: The primary purpose of an automatic storage-reclamation system for digital computers is to reclaim the memory occupied by memory objects that are no longer necessary for the correct operation of the computer programs that are clients of the reclamation system. Those objects that are unnecessary in this respect are commonly called garbage objects or, more simply, garbage, and the act of reclaiming such objects is commonly called garbage collection. Frequently, however, some final action or sequence of actions needs to be taken when a memory object becomes a garbage object, beyond simply reclaiming the memory occupied by such objects. An automated finalization mechanism performs such a pre-specified set of actions when it has determined that a memory object has become garbage. A postmortem finalization mechanism performs these finalization actions only after the garbage object has actually been reclaimed by the system's garbage collector. Delaying the execution of the finalization actions until the object in question has been fully reclaimed prevents this object from accidentally being resurrected as a possible side effect of the finalization actions. A mechanism for supporting postmortem finalization is constructed by extending the capabilities of an automatic storage-reclamation system.
TL;DR: A garbage collector, from time to time, and within a single cycle, determines objects that are eligible to have their associated memory freed; executes high priority finalizers associated with such eligible objects as are determined; and after execution of a high-priority finalizer, deallocates the memory of the associated object.
Abstract: A garbage collector, from time to time, and within a single cycle, determines objects that are eligible to have their associated memory freed; executes high-priority finalizers associated with such eligible objects as are determined; and after execution of a high-priority finalizer, deallocates the memory of the associated object. The garbage collector queues references to eligible objects that have non-high-priority finalizers in a list. After garbage collection is completed, a finalizer thread runs the queued non-high-priority finalizers and marks the associated objects as ready for deallocation. The garbage collector, during a subsequent cycle, then deallocates the memory associated with marked objects.
TL;DR: A view system for polymorphic initialization and finalization of objects is described in this article, which is not view system-specific, but is provided and used by the view system to support such behavior.
Abstract: A view system is disclosed which provides support polymorphic initialization and finalization of objects. This mechanism is used by the view system to support virtual method invocation at construction/destruction time for objects that require the needed behavior. The C++ language does not support the invocation of virtual methods from within the constructor/destructor of a given object. The view system provides a mechanism whereby an initialization method is invoked after the object construction is completed, but before any methods are invoked on the constructed object. A similar mechanism is used to invoke a virtual finalization method before the object destruction is started. This mechanism is not view system-specific, but is provided and used by the view system to support such behavior.
TL;DR: This paper is the first to present a formal mechanized account of the metatheory of construction and destruction in C++, and applications to popular programming techniques such as "resource acquisition is initialization".
Abstract: We present a formal operational semantics and its Coq mechanization for the C++ object model, featuring object construction and destruction, shared and repeated multiple inheritance, and virtual function call dispatch. These are key C++ language features for high-level system programming, in particular for predictable and reliable resource management. This paper is the first to present a formal mechanized account of the metatheory of construction and destruction in C++, and applications to popular programming techniques such as "resource acquisition is initialization". We also report on irregularities and apparent contradictions in the ISO C++03 and C++11 standards.
TL;DR: The authors have identified seven features that can lead to particularly resistant bugs in Java and suggest how programmers can make sure that Java's design flaws don't make implementation more difficult than it has to be.
Abstract: Despite Java attributes (memory management, strong type checking, and built-in support for exception handling) that promote reliable, bug-free software, some features contribute to, rather than alleviate, programmer stress because they create obscure places for bugs to hide. The authors have identified seven features that can lead to particularly resistant bugs. Their goal is not to indict Java-they are strong supporters, and their own organizations have adopted Java as their primary programming language. Rather, they want programmers to better understand Java's weaknesses and know how to cope with them. Being aware of these design weaknesses (Java's false sense of protection, constructor confusion, finalizer methods, subclass substitution, container limitations, final parameters, and initialization diffusion), programmers can make sure that Java's design flaws don't make implementation more difficult than it has to be.