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.
|
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.
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.
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.
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##
Brown, Paul C., Topka, Terry M.
Patent | Priority | Assignee | Title |
10185579, | May 15 2006 | AVAYA LLC | Dynamic multikeys for persistent objects |
10223163, | Jul 14 2016 | Microsoft Technology Licensing, LLC | Workflow-based object destruction |
10289728, | May 15 2006 | AVAYA LLC | Garbage collection of persistent objects with dynamic multikeys |
10324735, | May 15 2006 | AVAYA LLC | Method invocation for persistent objects with dynamic multikeys |
10437720, | Mar 12 2014 | OPTUMSOFT, INC | Deferred destruction for efficient resource reclamation |
10558439, | Apr 22 2013 | Embarcadero Technologies, Inc. | Automatic reference counting |
11157251, | Apr 22 2013 | Embarcadero Technologies, Inc. | Automatic reference counting |
11232026, | Mar 12 2014 | OptumSoft, Inc. | Deferred destruction for efficient resource reclamation |
5463770, | Jul 22 1992 | International Business Machines Corporation | System 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 |
5689707, | Dec 04 1995 | NCR Corporation | Method and apparatus for detecting memory leaks using expiration events and dependent pointers to indicate when a memory allocation should be de-allocated |
5765174, | Oct 06 1995 | Oracle America, Inc | System amd method for distributed object resource management |
5794256, | Dec 12 1996 | Microsoft Technology Licensing, LLC | Pointer swizzling facility using three-state references to manage access to referenced objects |
5799185, | Apr 10 1995 | Fuji Xerox Co., Ltd. | Method and system for managing system memory reclamation |
5819299, | Jun 06 1996 | Electric Communities | Process for distributed garbage collection |
5923877, | May 01 1996 | SAMSUNG ELECTRONICS CO , LTD | Object-oriented programming memory management framework and method |
5924107, | Jun 27 1994 | Fujitsu Ltd. | Information-processing apparatus having document-editing function |
5991779, | Jun 06 1996 | Electric Communities | Process for distributed garbage collection |
6081812, | Feb 06 1998 | TERADATA US, INC | Identifying at-risk components in systems with redundant components |
6098080, | May 05 1998 | International Business Machines Corporation | Computer system, program product and method of collecting interned data with a mark sweep collector |
6101525, | May 19 1995 | EMC IP HOLDING COMPANY LLC | Method and apparatus for shared memory cleanup |
6105041, | Dec 12 1996 | Microsoft Technology Licensing, LLC | Using three-state references to manage garbage collection of referenced objects |
6247077, | Feb 06 1998 | TERADATA US, INC | Highly-scalable parallel processing computer system architecture |
6253943, | Mar 11 1997 | Johnson Controls Technology Company | Storage divider |
6324550, | Aug 25 1999 | FORWARD PEOPLE PTY LIMITED ACN 106 380 812 | Data object identification and removal system |
6345276, | Sep 18 1998 | Microsoft Technology Licensing, LLC | Representing base pointers in a shared memory heap |
6363403, | Jun 30 1999 | WSOU Investments, LLC | Garbage collection in object oriented databases using transactional cyclic reference counting |
6366932, | Jun 24 1999 | International Business Machines Corporation | Apparatus and method for accessing an object oriented object using a smart passive reference |
6421690, | Apr 30 1998 | Honeywell International Inc | Computer memory management system |
6654773, | Feb 27 2001 | Tangie Data Holdings LLC | Method of deterministic garbage collection |
6799191, | May 16 2000 | Oracle America, Inc | Object sampling technique for runtime observations of representative instances thereof |
7203756, | Apr 27 2001 | International Business Machines Corporation | Mechanism to cache references to Java RMI remote objects implementing the unreferenced interface |
7770177, | Sep 29 2004 | Sony Corporation | System for memory reclamation based on thread entry and release request times |
8032886, | Nov 22 2000 | Microsoft Technology Licensing, LLC | Tracking asynchronous execution of program using hierarchical structure of objects |
8055689, | Mar 14 2005 | Oracle America, Inc | Methods and systems for distributing information model nodes in memory |
8209692, | Mar 27 2003 | International Business Machines Corporation | Deallocation of computer data in a multithreaded computer |
8234645, | Mar 27 2003 | International Business Machines Corporation | Deallocation of computer data in a multithreaded computer |
8566368, | Sep 29 2010 | ZHIGU HOLDINGS LIMITED | Garbage collection extensibility via managed code |
8838656, | Jul 31 2009 | Intel Corporation | Hardware-protected reference count-based memory management using weak references |
9274947, | Aug 19 2014 | Microsoft Technology Licensing, LLC | Non-precise garbage collection in non-cooperative systems |
9390006, | Jul 31 2012 | International Business Machines Corporation | Garbage collection of an object |
9785549, | Apr 27 2007 | Microsoft Technology Licensing, LLC | Managing object lifetime for native/managed peers |
9804963, | Jul 31 2009 | Intel Corporation | Hardware-protected reference count-based memory management using weak references |
RE42396, | Feb 27 2001 | Tangie Data Holdings LLC | Method of deterministic garbage collection |
Patent | Priority | Assignee | Title |
4695949, | Jul 19 1984 | Texas Instruments Incorporated; TEXAS INSTRUMENTS INCORPORATED, 13500 NORTH CENTRAL EXPRESSWAY, DALLAS, TX 75265 A DE CORP | Method for efficient support for reference counting |
4755939, | Dec 04 1985 | International Computers Limited | Garbage collection in a computer system |
4775932, | Jul 31 1984 | Texas Instruments Incorporated; TEXAS INSTRUMENTS INCORPORATED A CORP OF DE | Computer memory system with parallel garbage collection independent from an associated user processor |
4775934, | Jun 17 1986 | YEDA RESEARCH AND DEVELOPMENT CO , THE WEIZMANN INSTITUTE OF SCIENCE, A CORP OF ISRAEL | Method for concurrent logic program |
4807120, | Apr 30 1987 | TEXAS INSTRUMENTS INCORPORATED, 13500 NORTH CENTRAL EXPRESSWAY, DALLAS, TX 75265 A CORP OF DE | Temporal garbage collector with indirection cells |
4912629, | Jun 26 1986 | The United States of America as represented by the Administrator of the | Real-time garbage collection for list processing using restructured cells for increased reference counter size |
5241673, | Jun 05 1990 | OCE-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 |
5274804, | Nov 20 1991 | CINCOM SYSTEMS, INC | Automatic storage-reclamation postmortem finalization process |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 02 1992 | TOPKA, TERRY M | GENERAL ELECTRIC COMPANY A CORP OF NEW YORK | ASSIGNMENT OF ASSIGNORS INTEREST | 006093 | /0670 | |
Apr 02 1992 | BROWN, PAUL C | GENERAL ELECTRIC COMPANY A CORP OF NEW YORK | ASSIGNMENT OF ASSIGNORS INTEREST | 006093 | /0670 | |
Apr 06 1992 | General Electric Company | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Jan 11 1995 | ASPN: Payor Number Assigned. |
May 22 1998 | M183: Payment of Maintenance Fee, 4th Year, Large Entity. |
Oct 02 2002 | REM: Maintenance Fee Reminder Mailed. |
Mar 14 2003 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Mar 14 1998 | 4 years fee payment window open |
Sep 14 1998 | 6 months grace period start (w surcharge) |
Mar 14 1999 | patent expiry (for year 4) |
Mar 14 2001 | 2 years to revive unintentionally abandoned end. (for year 4) |
Mar 14 2002 | 8 years fee payment window open |
Sep 14 2002 | 6 months grace period start (w surcharge) |
Mar 14 2003 | patent expiry (for year 8) |
Mar 14 2005 | 2 years to revive unintentionally abandoned end. (for year 8) |
Mar 14 2006 | 12 years fee payment window open |
Sep 14 2006 | 6 months grace period start (w surcharge) |
Mar 14 2007 | patent expiry (for year 12) |
Mar 14 2009 | 2 years to revive unintentionally abandoned end. (for year 12) |