Search Images Maps Play YouTube News Gmail Drive More »
Sign in


  1. Advanced Patent Search
Publication numberUS5398334 A
Publication typeGrant
Application numberUS 07/863,924
Publication dateMar 14, 1995
Filing dateApr 6, 1992
Priority dateApr 6, 1992
Fee statusLapsed
Publication number07863924, 863924, US 5398334 A, US 5398334A, US-A-5398334, US5398334 A, US5398334A
InventorsPaul C. Brown, Terry M. Topka
Original AssigneeGeneral Electric Company
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
System for automatic garbage collection using strong and weak encapsulated pointers
US 5398334 A
The present invention solves both the dangling pointer problem and the garbage collection problem in software systems. Safe object pointers are divided into strong and weak pointers. Strong pointers point to an object unless they are explicitly assigned a new value, set to null, or destroyed. Weak pointers point to an object as long as the object has not been destroyed. If an object is destroyed, the weak pointer effectively becomes null, thus allowing the breaking up of cycles of references in a computer memory.
Previous page
Next page
What is claimed is:
1. A method for automatic garbage collection in a software system comprising the steps of:
using strong pointers belonging to an application being run on said software system to reference objects therein, said objects maintaining a reference count of each strong pointer pointing thereto;
identifying cycles of strong pointers to objects in said software system;
replacing at least one of the strong pointers to said objects in said identified cycles with a volatile weak encapsulated pointer belonging to the application being run on said software system, said objects maintaining a separate reference count for each volatile weak pointer pointing thereto, said objects decreasing the strong pointer reference count as a volatile weak pointer is replaced for a strong pointer;
destroying any object as the strong pointer count reaches zero or as the volatile weak reference count reaches zero if and only if the strong pointer count is zero; and
determining whether said objects in said identified cycles are safely referenced, said objects being safely referenced if the strong reference count is greater than zero.

This invention relates to the field of computer programming in general and more specifically to the solution of the dangling pointer problem and the garbage collection problem.


In software it is frequently necessary for one part of a program to make reference to a program element such as a data structure that was constructed by some other portion of the program. Such elements are commonly referred to as objects. The means commonly employed for referring to an object is to use a pointer to the object. A problem arises when the object being pointed to is destroyed and a subsequent attempt is made to use the pointer to access the object. This usually leads to a fatal program error. This is commonly referred to as the dangling pointer problem.

One approach to solving the dangling pointer problem is to count the number of references to an object. Since objects can not be safely destroyed until all references to them are removed, object destruction is postponed until the pointer count reaches zero. This presents a problem when circular references exist. In FIG. 1, objects A and B have pointers to each other and some other global pointer (somewhere else in the program) refers to object A. It can be assumed that the pointers shown are all of the existing pointers to A and B. If the global pointer is removed (either destroyed or made to point to another object), objects A and B remain inaccessible from the rest of the program. However they cannot be destroyed, since each has one remaining pointer to it. Objects A and B are garbage as far as the rest of the program is concerned. The problem of identifying them as garbage, and removing them is known as the garbage collection problem.

To deal with the garbage collection problem, previous pointer counting schemes have required the application programmer to explicitly identify situations such as just described, and to write code that explicitly removes some pointers, such as the pointer from B to A in FIG. 1. After the removal of these pointers, some objects (A in this example) will have no remaining pointers and can be destroyed. In the process of destruction, the pointers that these objects have to other objects are also destroyed (in this example, the pointer from A to B) leaving others objects (B) with no remaining pointers. The process continues until all isolated objects have been destroyed. The problem with this approach is not the writing of the code that dismantles the pointers but is determining when to call the code. The programmer must determine when each segment becomes isolated.

The garbage collection problem has a serious effect on the software development process. Despite continuing advances in language and software technology, the proper management of memory continues to constitute a large portion of the overall effort required to develop software systems. In the popular C language, the simplicity of malloc ( ) and free ( ) has great appeal. However, this simplicity does have its costs. It is simply too easy to prematurely free memory and then attempt to reference that memory with a dangling pointer, or to fail to free memory altogether, creating a memory leak. Unfortunately, it is usually very hard to locate and fix these types of errors once they have been made. They are usually the types of errors that can remain undetected despite testing, possibly leading to dangerous and expensive failures of software in the field.

From the programmer's point of view, the best remedy to these problems is automatic garbage collection. In languages that support automatic garbage collection, memory management becomes trivial: one simply allocates an object whenever needed, with no worry about deallocating it. Most automatic garbage collection schemes have depended upon exhaustive searches through an application's data space for any and all references to objects. However, another mechanism is needed because the processing requirements of such exhaustive searches makes this technique too inefficient for most current C and C++ applications.


According to the present invention a method is provided for performing automatic garbage collection in a software system. Cycles of pointers to objects are first identified and at least one of the pointers in the cycle is replaced with a weak encapsulated pointer. This weak pointer will point to an object until the object is destroyed. It will not prevent an object from being destroyed but will instead safely become a null pointer upon the destruction of an object to which it points. The use of weak encapsulated pointers to break cycles aids in the garbage collection process since the absence of cycles ensure that segments will be destroyed when they become isolated from the rest of the program. An object being pointed to by a weak pointer may be safely destroyed as long as the count of strong pointers to it has decremented to zero. Once destroyed, all of the pointers from the object to other objects also go away thus allowing for more objects to be destroyed until the "garbage" is effectively eliminated from the system.


FIG. 2 is a schematic view of a simple data structure benefitting from the use of the strong and weak encapsulated pointers of the present invention. Strong encapsulated pointers 110 and 130 and weak encapsulated pointer 120 are supported by maintaining separate reference counts on the objects. A's reference count of two consists of a strong count of one and a weak count of one. If pointer 130 is removed, A's strong reference count decrements to zero, which causes A to be destroyed despite its non-zero weak reference count. B's weak pointer referring to A safely becomes a null pointer. The destruction of A causes its strong encapsulated pointer 130 referring to B to be destroyed; this causes B's strong reference count to decrement to zero, which causes B to also be destroyed. The garbage has thus been eliminated from the memory of the computer.

The data structures for an application must be designed so that every cycle of references that exists contains at least one weak encapsulated pointer. Automatic garbage collection will not occur in applications whose data structures contain cycles of strong encapsulated pointers. In this case memory management must again be performed explicitly by the application, although the application still benefits from the use of safe encapsulated pointers.

To take advantage of the present invention, a programmer must first identify cycles of references. At least one weak pointer must be used within the cycle. When the objects in the cycle become isolated from the rest of the program, the cycle will automatically be destroyed through a normal counted pointer scheme as applied to the strong pointers only. The novel aspect of the present invention is the use of the weak pointer as described above.

The concept of an encapsulated or "smart" pointer is not new. Such a pointer behaves like a regular pointer but performs the additional function of updating a reference count on each access through them. When an encapsulated pointer is made to point to a particular object, it informs the object. The object in turn keeps track of the number of encapsulated pointers that refer to it. By examining the count of pointers on an object, it can be determined when the object may safely be destroyed without creating any dangling pointers. Prior art encapsulated pointers do not, however, handle the problem of cyclic references as described in the background section. The use of strong and weak encapsulated pointers does handle the problem.

Strong encapsulated pointers forever point to an object, unless they are explicitly assigned a new value, set to null, or destroyed. The existence of a strong encapsulated pointer to an object insures that the object is never destroyed; thus it is always safe to reference the object through that strong encapsulated pointer. Weak encapsulated pointers point to an object as long as the object has not been destroyed, and otherwise safely become null. Weak encapsulated pointers are volatile; objects can safely be referenced through a weak encapsulated pointer once an explicit check for the null value has been performed.

Appendix A includes source code which implements the present invention.

While specific embodiments of the invention have been illustrated and described herein, it is realized that modifications and changes will occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit and scope of the invention. ##SPC1##


While the novel features of the invention are set forth with particularity in the appended claims, the invention, both as to organization and content, will be better understood and appreciated, along with other objects and features thereof, from the following detailed description taken in conjunction with the drawings, in which:

FIG. 1 is a schematic view of a simple data structure containing a cycle of pointers.


Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4695949 *Jul 19, 1984Sep 22, 1987Texas Instruments IncorporatedMethod for efficient support for reference counting
US4755939 *Nov 24, 1986Jul 5, 1988International Computers LimitedGarbage collection in a computer system
US4775932 *Jul 31, 1984Oct 4, 1988Texas Instruments IncorporatedComputer memory system with parallel garbage collection independent from an associated user processor
US4775934 *Jun 17, 1986Oct 4, 1988Yeda Research And Development Co.Method for concurrent logic program
US4807120 *Apr 30, 1987Feb 21, 1989Texas Instruments IncorporatedTemporal garbage collector with indirection cells
US4912629 *Jun 26, 1986Mar 27, 1990The United States Of America As Represented By The Administrator Of The National Aeronautics And Space AdministrationReal-time garbage collection for list processing using restructured cells for increased reference counter size
US5241673 *Oct 1, 1990Aug 31, 1993Oce-Nederland B.V.System for garbage collecting unused memory space represented by a digraph by assigning values of node identifiers to selected variables based upon predetermined conditions
US5274804 *Nov 20, 1991Dec 28, 1993Parcplace SystemsAutomatic storage-reclamation postmortem finalization process
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US5463770 *Mar 6, 1995Oct 31, 1995International Business Machines CorporationSystem and method for controlling data storage in a data processing system in which objects generated within a lower level language program are associated with memory slots allocated to another program
US5689707 *Dec 4, 1995Nov 18, 1997Ncr CorporationMethod and apparatus for detecting memory leaks using expiration events and dependent pointers to indicate when a memory allocation should be de-allocated
US5765174 *Oct 6, 1995Jun 9, 1998Sun Microsystems, Inc.System amd method for distributed object resource management
US5794256 *Dec 12, 1996Aug 11, 1998Microsoft CorporationPointer swizzling facility using three-state references to manage access to referenced objects
US5799185 *Mar 29, 1996Aug 25, 1998Fuji Xerox Co., Ltd.Method and system for managing system memory reclamation
US5819299 *Jun 6, 1996Oct 6, 1998Electric CommunitiesProcess for distributed garbage collection
US5923877 *May 1, 1996Jul 13, 1999Electronic Data Systems CorporationObject-oriented programming memory management framework and method
US5924107 *Sep 29, 1997Jul 13, 1999Fujitsu Ltd.Information-processing apparatus having document-editing function
US5991779 *Sep 14, 1998Nov 23, 1999Electric CommunitiesProcess for distributed garbage collection
US6081812 *Feb 6, 1998Jun 27, 2000Ncr CorporationIdentifying at-risk components in systems with redundant components
US6098080 *May 5, 1998Aug 1, 2000International Business Machines CorporationComputer system, program product and method of collecting interned data with a mark sweep collector
US6101525 *May 19, 1995Aug 8, 2000Emc CorporationMethod and apparatus for shared memory cleanup
US6105041 *May 21, 1998Aug 15, 2000Microsoft CorporationUsing three-state references to manage garbage collection of referenced objects
US6247077Feb 6, 1998Jun 12, 2001Ncr CorporationHighly-scalable parallel processing computer system architecture
US6253943Nov 5, 1998Jul 3, 2001Prince Technology CorporationStorage divider
US6324550 *Dec 29, 1999Nov 27, 2001Bullant Technology Pty LtdData object identification and removal system
US6345276 *Sep 18, 1998Feb 5, 2002Microsoft CorporationRepresenting base pointers in a shared memory heap
US6363403 *Jun 30, 1999Mar 26, 2002Lucent Technologies Inc.Garbage collection in object oriented databases using transactional cyclic reference counting
US6366932 *Jun 24, 1999Apr 2, 2002International Business Machines CorporationApparatus and method for accessing an object oriented object using a smart passive reference
US6421690 *Apr 29, 1999Jul 16, 2002Honeywell International Inc.Computer memory management system
US6654773Feb 27, 2001Nov 25, 2003Tajea CorporationMethod of deterministic garbage collection
US6799191May 15, 2001Sep 28, 2004Sun Microsystems, Inc.Object sampling technique for runtime observations of representative instances thereof
US7203756 *Apr 27, 2001Apr 10, 2007International Business Machines CorporationMechanism to cache references to Java RMI remote objects implementing the unreferenced interface
US7770177 *Sep 2, 2005Aug 3, 2010Sony CorporationSystem for memory reclamation based on thread entry and release request times
US8032886 *Oct 17, 2005Oct 4, 2011Microsoft CorporationTracking asynchronous execution of program using hierarchical structure of objects
US8055689 *Mar 14, 2005Nov 8, 2011Oracle America, Inc.Methods and systems for distributing information model nodes in memory
US8209692 *Oct 29, 2007Jun 26, 2012International Business Machines CorporationDeallocation of computer data in a multithreaded computer
US8234645Jan 8, 2008Jul 31, 2012International Business Machines CorporationDeallocation of computer data in a multithreaded computer
US8566368Sep 29, 2010Oct 22, 2013Microsoft CorporationGarbage collection extensibility via managed code
USRE42396Nov 23, 2005May 24, 2011Tangie Data Holdings LlcMethod of deterministic garbage collection
EP0767432A2 *Sep 2, 1996Apr 9, 1997Sun Microsystems, Inc.System and method for distributed object resource management
EP1255191A2 *Apr 26, 2002Nov 6, 2002AlcatelInstance-reduction algorithm for garbage-collected language
WO1997046930A2 *Jun 5, 1997Dec 11, 1997Electric CommunitiesProcess for distributed garbage collection
WO2000000894A2 *Jun 14, 1999Jan 6, 2000Koninkl Philips Electronics NvReference counting mechanism for garbage collectors
WO2001088709A2 *May 16, 2001Nov 22, 2001Sun Microsystems IncObject sampling technique for runtime observations of representative instances thereof
U.S. Classification1/1, 711/E12.01, 707/999.206
International ClassificationG06F12/02, G06F9/44, G06F12/00, G06F17/30
Cooperative ClassificationY10S707/99957, G06F17/30607, G06F12/0261
European ClassificationG06F12/02D2G2, G06F17/30S8T
Legal Events
May 13, 2003FPExpired due to failure to pay maintenance fee
Effective date: 20030314
Mar 14, 2003LAPSLapse for failure to pay maintenance fees
Oct 2, 2002REMIMaintenance fee reminder mailed
May 22, 1998FPAYFee payment
Year of fee payment: 4
Apr 6, 1992ASAssignment
Effective date: 19920402