261:, which incurs an additional cost. There are three reasons for the atomicity requirements. First, a reference count field may be updated by multiple threads, and so an adequate atomic instruction, such as a (costly) compare-and-swap, must be used to update the counts. Second, it must be clear which object loses a reference so that its reference count can be adequately decremented. But determining this object is non-trivial in a setting where multiple threads attempt to modify the same reference (i.e., when data races are possible). Finally, there exists a subtle race in which one thread gains a pointer to an object, but before it increments the object's reference count, all other references to this object are deleted concurrently by other threads and the object is reclaimed, causing the said thread to increment a reference count of a reclaimed object.
334:, in which references which are stored in local variables do not immediately increment the corresponding reference count, but instead defer this until it is necessary. If such a reference is destroyed quickly, then there is no need to update the counter. This eliminates a large number of updates associated with short-lived references (such as the above list-length-counting example). However, if such a reference is copied into a data structure, then the deferred increment must be performed at that time. It is also critical to perform the deferred increment before the object's count drops to zero, to avoid a premature free.
2344:
2334:
2324:
2314:
2304:
38:
479:, and each object tracks not the number of references referring to it, but the total weight of the references referring to it. The initial reference to a newly created object has a large weight, such as 2. Whenever this reference is copied, half of the weight goes to the new reference, and half of the weight stays with the old reference. Since the total weight does not change, the object's reference count does not need to be updated.
190:
1052:). Since Tcl's values are immutable, reference cycles are impossible to form and no cycle detection scheme is needed. Operations that would replace a value with a modified copy are generally optimized to instead modify the original when its reference count indicates that it is not shared. The references are counted at a data structure level, so the problems with very frequent updates discussed above do not arise.
728:, and interfaces, for ease of use and to simplify the generic database functionality. It is up to the programmer to decide whether to use the built-in types; Delphi programmers have complete access to low-level memory management like in C/C++. So all potential cost of Delphi's reference counting can, if desired, be easily circumvented.
749:
The reference count of a string is checked before mutating a string. This allows reference count 1 strings to be mutated directly whilst higher reference count strings are copied before mutation. This allows the general behaviour of old style pascal strings to be preserved whilst eliminating the cost
535:
When an object is destroyed, any objects referenced by that object also have their reference counts decreased. Because of this, removing a single reference can potentially lead to a large number of objects being freed. A common modification allows reference counting to be made incremental: instead of
294:
of its vertex. Deleting a vertex is like collecting an object. It can only be done when the vertex has no incoming edges, so it does not affect the out-degree of any other vertices, but it can affect the in-degree of other vertices, causing their corresponding objects to be collected as well if their
232:
and cache line faults, they collect relatively infrequently, while accessing objects is done continually. Also, less importantly, reference counting requires every memory-managed object to reserve space for a reference count. In tracing garbage collectors, this information is stored implicitly in the
490:
The property of not needing to access a reference count when a reference is copied is particularly helpful when the object's reference count is expensive to access, for example because it is in another process, on disk, or even across a network. It can also help increase concurrency by avoiding many
457:
list, and then periodically the program searches through the objects reachable from the roots for cycles. It knows it has found a cycle that can be collected when decrementing all the reference counts on a cycle of references brings them all down to zero. An enhanced version of this algorithm by Paz
298:
The connected component containing the special vertex contains the objects that can't be collected, while other connected components of the graph only contain garbage. If a reference-counting garbage collection algorithm is implemented, then each of these garbage components must contain at least one
265:
In addition to these, if the memory is allocated from a free list, reference counting suffers from poor locality. Reference counting alone cannot move objects to improve cache performance, so high performance collectors implement a tracing garbage collector as well. Most implementations (such as the
810:
uses a reference counting mechanism for its internal variable management. Since PHP 5.3, it implements the algorithm from Bacon's above mentioned paper. PHP allows you to turn on and off the cycle collection with user-level functions. It also allows you to manually force the purging mechanism to be
408:
method in 2003 combines deferred reference counting with a copying nursery, observing that the majority of pointer mutations occur in young objects. This algorithm achieves throughput comparable with the fastest generational copying collectors with the low bounded pause times of reference counting.
245:
an object which refers directly or indirectly to itself. A mechanism relying purely on reference counts will never consider cyclic chains of objects for deletion, since their reference count is guaranteed to stay nonzero (cf. picture). Methods for dealing with this issue exist but can also increase
494:
The primary problem with simple weighted reference counting is that destroying a reference still requires accessing the reference count, and if many references are destroyed, this can cause the same bottlenecks we seek to avoid. Some adaptations of weighted reference counting seek to avoid this by
452:
Bacon describes a cycle-collection algorithm for reference counting with similarities to tracing collectors, including the same theoretical time bounds. It is based on the observation that a cycle can only be isolated when a reference count is decremented to a nonzero value. All objects which this
286:
are objects and there is an edge from an object A to an object B if A holds a reference to B. We also have a special vertex or vertices representing the local variables and references held by the runtime system, and no edges ever go to these nodes, although edges can go from them to
177:
they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object. In real-time applications or systems with limited memory, this is important to maintain responsiveness. Reference counting is also among the
432:
Systems may also be designed to tolerate or correct the cycles they create in some way. Developers may design code to explicitly "tear down" the references in a data structure when it is no longer needed, though this has the cost of requiring them to manually track that data structure's lifetime.
400:
during pointer updates in a concurrent setting, this solving reference counting issues in a concurrent setting. Therefore, update coalescing solves the third problem of naive reference counting (i.e., a costly overhead in a concurrent setting). Levanoni and
Petrank presented an enhanced algorithm
741:
The overhead in code size required for reference counting is very small (on native x86, typically a single LOCK INC, LOCK DEC or LOCK XADD instruction, which ensures atomicity in any environment), and no separate thread of control is needed for collection as would be needed for a tracing garbage
579:
One primary motivation for reference counting in COM is to enable interoperability across different programming languages and runtime systems. A client need only know how to invoke object methods in order to manage object life cycle; thus, the client is completely abstracted from whatever memory
437:
object's destructor could delete the edges of its GraphNodes, breaking the reference cycles in the graph. Cycles may even be ignored in systems with short lives and a small amount of cyclic garbage, particularly when the system was developed using a methodology of avoiding cyclic data structures
322:
The
Deutsch-Bobrow method of reference counting capitalizes on the fact that most reference count updates are in fact generated by references stored in local variables. It ignores these references, only counting references in data structures, but before an object with reference count zero can be
482:
Destroying a reference decrements the total weight by the weight of that reference. When the total weight becomes zero, all references have been destroyed. If an attempt is made to copy a reference with a weight of 1, the reference has to "get more weight" by adding to the total weight and then
753:
Because garbage-collection is only done on built-in types, reference counting can be efficiently integrated into the library routines used to manipulate each datatype, keeping the overhead needed for updating of reference counts low. Moreover, a lot of the runtime library is in hand-optimized
318:
One simple technique is for the compiler to combine a number of nearby reference updates into one. This is especially effective for references which are created and quickly destroyed. Care must be taken, however, to put the combined update at the right position so that a premature free can be
466:
Although it is possible to augment simple reference counts in a variety of ways, often a better solution can be found by performing reference counting in a fundamentally different way. Here we describe some of the variants on reference counting and their benefits and drawbacks.
592:
C++ does not perform reference-counting by default, fulfilling its philosophy of not adding functionality that might incur overheads where the user has not explicitly requested it. Objects that are shared but not owned can be accessed via a reference, raw pointer, or
539:
Simple reference counts require frequent updates. Whenever a reference is destroyed or overwritten, the reference count of the object it references is decremented, and whenever one is created or copied, the reference count of the object it references is incremented.
392:
Levanoni and
Petrank showed in 2001 how to use such update coalescing in a reference counting collector. When using update coalescing with an appropriate treatment of new objects, more than 99% of the counter updates are eliminated for typical Java benchmarks.
510:
In indirect reference counting, it is necessary to keep track of the reference's source. This means that two references are kept to the object: a direct one which is used for invocations; and an indirect one which forms part of a diffusion tree, such as in the
745:
Many instances of the most commonly used garbage-collected type, the string, have a short lifetime, since they are typically intermediate values in string manipulation. A lot of local string usage could be optimized away, but the compiler currently doesn't do
201:
Tracing garbage collection cycles are triggered too often if the set of live objects fills most of the available memory; it requires extra space to be efficient. Reference counting performance does not deteriorate as the total amount of free space decreases.
1017:
uses reference counting with cycle detection. This tiny language is relatively unknown outside the video game industry; however, it is a concrete example of how reference counting can be practical and efficient (especially in realtime environments).
723:
is mostly not a garbage collected language, in that user-defined types must still be manually allocated and deallocated; however, it does provide automatic collection using reference counting for a few built-in types, such as strings,
757:
The string type can be cast to a pointer to char, and high performance operations can be performed that way. This is important since both Delphi and FPC implement their RTL in Pascal. Various other automated types have such casting
178:
simplest forms of memory management to implement. It also allows for effective management of non-memory resources such as operating system objects, which are often much scarcer than memory (tracing garbage collection systems use
543:
Reference counting is also used in file systems and distributed systems, where full non-incremental tracing garbage collection is too time-consuming because of the size of the object graph and slow access speed.
779:
for thread safety. A significant amount of the work in writing bindings to GObject from high-level languages lies in adapting GObject reference counting to work with the language's own memory management system.
637:
further reduce the extent to which reference counts need to be modified by removing the deep copy normally used when a function returns an object, as it allows for a simple copy of the pointer of said object.
1063:
also uses reference counting, without any special handling of circular references, although (as in Cocoa and C++ above), Xojo does support weak references, which allows programmers to avoid creating a cycle.
798:
also uses reference counting, without any special handling of circular references, although (as in Cocoa and C++ above), Perl does support weak references, which allows programmers to avoid creating a cycle.
246:
the overhead and complexity of reference counting — on the other hand, these methods need only be applied to data that might form cycles, often a small subset of all data. One such method is the use of
217:) knows that a particular object has only one reference (as most do in many systems), and that the reference is lost at the same time that a similar new object is created (as in the string append statement
738:
Cycles either cannot occur or do not occur in practice because none of the garbage-collected built-in types are recursive. (using interfaces one could create such scenario, but that is not common usage)
980:
Using these constructs allows programmers to avoid lifetimes for a small runtime cost. Both reference counters keep track of the number of owners, as they must drop themselves when no owners remain.
1423:
536:
destroying an object as soon as its reference count becomes zero, it is added to a list of unreferenced objects, and periodically (or as needed) one or more items from this list are destroyed.
1109:
449:
to reclaim cycles; since cycles typically constitute a relatively small amount of reclaimed space, the collector can be run much less often than with an ordinary tracing garbage collector.
307:
Incrementing and decrementing reference counts every time a reference is created or destroyed can significantly impede performance. Not only do the operations take time, but they damage
345:
which coalesces many of the redundant reference count updates. Consider a pointer that in a given interval of the execution is updated several times. It first points to an object
1708:
417:
Perhaps the most obvious way to handle reference cycles is to design the system to avoid creating them. A system may explicitly forbid reference cycles; file systems with
1659:
233:
references that refer to that object, saving space, although tracing garbage collectors, particularly incremental ones, can require additional space for other purposes.
584:
program using a COM object is agnostic towards whether that object was allocated (and must later be deallocated) by a C++ allocator or another Visual Basic component.
491:
threads locking a reference count to increase it. Thus, weighted reference counting is most useful in parallel, multiprocess, database, or distributed applications.
315:. Even read-only operations like calculating the length of a list require a large number of reads and writes for reference updates with naive reference counting.
224:
Reference counting in naive form has three main disadvantages over the tracing garbage collection, both of which require additional mechanisms to ameliorate:
1498:
624:) to break cyclic dependencies. Objects that are dynamically allocated but not intended to be shared can have their lifetime automatically managed using a
429:
framework, for instance, recommends using "strong" references for parent-to-child relationships and "weak" references for child-to-parent relationships.
1836:
381:. But most of these updates are redundant. In order to have the reference count properly evaluated at the end of the interval it is enough to perform
1543:
1446:
1193:
458:
et al. is able to run concurrently with other operations and improve its efficiency by using the update coalescing method of
Levanoni and Petrank.
983:
One noteworthy facet of these types is related to their usage as a shared reference. In Rust, shared references cannot mutate their held data, so
841:
However, the language also offers various alternatives to complex forms of memory management. Reference counting functionality is provided by the
445:
and collect reference cycles automatically, without requiring changes in the data structure design. One simple solution is to periodically use a
1858:
2284:
1945:
205:
Reference counts are also useful information to use as input to other runtime optimizations. For example, systems that depend heavily on
299:
cycle; otherwise, they would have been collected as soon as their reference count (i.e., the number of incoming edges) dropped to zero.
1716:
532:
to it held by other objects. If an object's reference count reaches zero, the object has become inaccessible, and can be destroyed.
228:
The frequent updates it involves are a source of inefficiency. While tracing garbage collectors can impact efficiency severely via
614:
class, enabling automatic shared memory-management of dynamically allocated objects. Programmers can use this in conjunction with
576:, and countless third-party products) are built on COM, demonstrating the viability of reference counting in large-scale systems.
1993:
102:
515:, which allows a garbage collector to identify dead objects. This approach prevents an object from being discarded prematurely.
433:
This technique can be automated by creating an "owner" object that does the tearing-down when it is destroyed; for instance, a
74:
1091:, some Unixes only allow references from live processes, and there can be files that exist outside the file system hierarchy.
2337:
2141:
1965:
1469:
158:
1210:(September 1994). "Minimizing Reference Count Updating with Deferred and Anchored Pointers for Functional Data Structures".
2368:
2327:
1643:
838:
when it falls out of scope. When a programmer needs to define the scope of a constructed type, they often use lifetimes.
81:
2347:
1388:
Proceedings of the 18th annual ACM SIGPLAN conference on Object-oriented programing, systems, languages, and applications
55:
1901:
Atomic
Reference Counting Pointers: A lock-free, async-free, thread-safe, multiprocessor-safe reference counting pointer
731:
Some of the reasons reference counting may have been preferred to other forms of garbage collection in Delphi include:
560:
makes pervasive use of reference counting. In fact, two of the three methods that all COM objects must provide (in the
1591:
1566:
1407:
1142:
835:
121:
88:
1270:
Proceedings of the 16th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
1207:
327:
323:
deleted, the system must verify with a scan of the stack and registers that no other reference to it still exists.
2164:
1938:
787:
uses GObject reference counting as its primary garbage collection system, along with copy-heavy string handling.
512:
483:
adding this new weight to the reference, and then splitting it. An alternative in this situation is to create an
210:
17:
1582:
Watson, Paul; Watson, Ian (1987). "An efficient garbage collection scheme for parallel computer architectures".
2289:
1682:
1006:
has performance costs, too, so, for maximum performance, some applications may call for additional complexity.
442:
147:
70:
59:
1607:
Bruno, Rodrigo; Ferreira, Paulo (2018). "A Study on
Garbage Collection Algorithms for Big Data Environments".
1034:
1014:
819:
720:
266:
ones in PHP and
Objective-C) suffer from poor cache performance since they do not implement copying objects.
2149:
1987:
1087:. When the count reaches zero, the file can be safely deallocated. While references can still be made from
1026:
677:
647:
529:
143:
2126:
831:
784:
696:
introduced a tracing garbage collector as an alternative to reference counting, but it was deprecated in
569:
499:
487:
reference object, the initial reference to which is created with a large weight which can then be split.
1491:
1475:
1111:
The
Feasibility of Automatic Storage Reclamation with Concurrent Program Execution in a LISP Environment
2373:
2307:
2194:
2184:
2174:
2027:
1931:
1130:
446:
434:
170:
1158:
2253:
1380:
1785:
822:
also uses reference counting and offers cycle detection as well (and can reclaim reference cycles).
2113:
1760:
1512:
1320:
1187:
1088:
257:
In a concurrent setting, all updates of the reference counts and all pointer modifications must be
197:, with reference counts. Even if the incoming top left pointer is removed, all counts remain >0.
1886:
1226:
2317:
2179:
2154:
2060:
1160:
771:
object-oriented programming framework implements reference counting on its base types, including
48:
1909:
Extending and
Embedding the Python Interpreter: Extending Python with C or C++: Reference Counts
528:
As a collection algorithm, reference counting tracks, for each object, a count of the number of
95:
2131:
2083:
1981:
1832:
1507:
1315:
1221:
665:
600:
However, by the same token, C++ provides native ways for users to opt-into such functionality:
553:
401:
that may run concurrently with multithreaded applications employing only fine synchronization.
1168:
24th ACM SIGPLAN conference on Object
Oriented Programming Systems, Languages and Applications
2159:
1537:
1072:
Many file systems maintain reference counts to any particular block or file, for example the
283:
1891:
1351:
1029:
uses reference counting to track and manage the memory of class instances, and provides the
1899:
161:
algorithms, reference counts may be used to deallocate objects that are no longer needed.
8:
2037:
1738:
1303:
1265:
1212:
2279:
2263:
1624:
1525:
1333:
1239:
151:
834:
does not provide reference counting by default. Instead, any constructed type will be
213:
can suffer an efficiency penalty due to frequent copies. However, if the compiler (or
2055:
1954:
1587:
1562:
1465:
1403:
1138:
397:
258:
1628:
1337:
1243:
337:
A dramatic decrease in the overhead on counter updates was obtained by Levanoni and
2232:
2227:
2070:
1616:
1584:
Volume II: Parallel Languages on PARLE: Parallel Architectures and Languages Europe
1559:
Volume II: Parallel Languages on PARLE: Parallel Architectures and Languages Europe
1529:
1517:
1457:
1395:
1325:
1277:
1231:
1175:
776:
684:
compiler feature that automatically inserts these messages as needed, was added in
594:
573:
206:
135:
274:
When dealing with garbage collection schemes, it is often helpful to think of the
2222:
2121:
1907:
1647:
1641:
1080:
701:
661:
557:
312:
1557:
Bevan, D. I. (1987). "Distributed garbage collection using reference counting".
2237:
2204:
2199:
2045:
2004:
1159:
Rifat Shahriyar, Stephen M. Blackburn, Xi Yang and Kathryn S. McKinley (2013).
772:
634:
605:
422:
279:
251:
247:
229:
214:
2362:
2214:
2017:
2012:
1915:
1461:
725:
693:
689:
580:
allocator the implementation of the COM object uses. As a typical example, a
565:
154:
to a resource, such as an object, a block of memory, disk space, and others.
1521:
1329:
1179:
1887:
The Memory Manager Reference: Beginner's Guide: Recycling: Reference Counts
1493:
1299:
1261:
705:
615:
581:
338:
1399:
1381:"Ulterior Reference Counting: Fast Garbage Collection without a Long Wait"
1281:
1235:
2258:
685:
668:. Traditionally this was accomplished by the programmer manually sending
657:
653:
426:
353:, and so forth until at the end of the interval it points to some object
221:), it can replace the operation with a mutation on the original object.
2022:
1456:. Lecture Notes in Computer Science. Vol. 2072. pp. 207–235.
1084:
625:
619:
609:
735:
The general benefits of reference counting, such as prompt collection.
2169:
2050:
697:
418:
308:
291:
193:
Circular list example from a 1985 Master's Thesis. Rectangles denote
179:
1923:
1807:
1620:
564:
interface) increment or decrement the reference count. Much of the
396:
Interestingly, update coalescing also eliminates the need to employ
37:
2103:
2098:
2088:
2078:
1048:
8 uses reference counting for memory management of values (Tcl Obj
561:
495:
transferring weight from a dying reference to an active reference.
189:
1496:, V. T. Rajan (2007). "An efficient on-the-fly cycle collection".
2093:
1786:"1. Extending Python with C or C++ — Python 2.7.11 documentation"
1586:. Eindhoven, The Netherlands: Springer-Verlag. pp. 432–443.
1561:. Eindhoven, The Netherlands: Springer-Verlag. pp. 176–187.
1378:
768:
601:
186:
are a good solution for garbage collecting a distributed system.
290:
In this context, the simple reference count of an object is the
1917:
Down for the count? Getting reference counting back in the ring
1391:
1273:
1171:
1049:
1135:
Proceedings of the International Workshop on Memory Management
1352:"An On-the-Fly Reference-Counting Garbage Collector for Java"
1304:"An on-the-fly reference-counting garbage collector for java"
1266:"An on-the-fly reference-counting garbage collector for java"
1073:
860:, allocated on the heap for multiple references to its data.
681:
475:
In weighted reference counting, each reference is assigned a
1297:
1259:
1919:, Rifat Shahriyar, Stephen M. Blackburn and Daniel Frampton
1893:
An On-the-Fly Reference-Counting Garbage Collector for Java
1060:
795:
438:
wherever possible, typically at the expense of efficiency.
194:
182:
for this, but the delayed reclamation may cause problems).
1447:"Concurrent Cycle Collection in Reference Counted Systems"
1117:(Master's thesis). Naval Postgraduate School, Monterey/CA.
1045:
807:
709:
498:
Weighted reference counting was independently devised by
357:. A reference counting algorithm would typically execute
999:, in contexts where interior mutability is necessary.
302:
1966:
Memory management as a function of an operating system
849:
types, which are non-atomic and atomic respectively.
1499:
ACM Transactions on Programming Languages and Systems
1161:"Taking Off the Gloves with Reference Counting Immix"
254:
algorithm that gets called infrequently to clean up.
142:
is a programming technique of storing the number of
1033:keyword for creating weak references. Instances of
62:. Unsourced material may be challenged and removed.
1683:"OS X 10.8 Mountain Lion: the Ars Technica review"
169:The main advantage of the reference counting over
712:has never supported a tracing garbage collector.
441:Computer scientists have also discovered ways to
236:The naive algorithm described above can't handle
2360:
1107:
412:
183:
1739:"Projects/Vala/ReferenceHandling - GNOME Wiki!"
1492:Harel Paz, David F. Bacon, Elliot K. Kolodner,
775:. Reference incrementing and decrementing uses
164:
1137:. London, UK: Springer-Verlag. pp. 1–42.
505:
470:
1939:
1606:
856:provides shared ownership of a value of type
2285:International Symposium on Memory Management
1581:
1542:: CS1 maint: multiple names: authors list (
1379:Stephen Blackburn; Kathryn McKinley (2003).
1192:: CS1 maint: multiple names: authors list (
1131:"Uniprocessor Garbage Collection Techniques"
660:frameworks (and related frameworks, such as
1206:
664:) use manual reference counting, much like
597:(a conceptual generalisation of pointers).
1946:
1932:
1444:
750:of copying the string on every assignment.
1761:"PHP: Reference Counting Basics - Manual"
1511:
1319:
1293:
1291:
1255:
1253:
1225:
568:and many Windows applications (including
547:
389:. The rest of the updates are redundant.
122:Learn how and when to remove this message
1680:
1454:ECOOP 2001 — Object-Oriented Programming
188:
1689:. At section "Objective-C enhancements"
425:may also help avoid retain cycles; the
269:
14:
2361:
1445:Bacon, David F.; Rajan, V. T. (2001).
1288:
1250:
1128:
641:
295:in-degree also becomes 0 as a result.
1953:
1927:
1835:. 21 July 2022. Interior Mutability.
1556:
523:
303:Dealing with inefficiency of updates
60:adding citations to reliable sources
31:
27:Software resource tracking technique
1994:Input–output memory management unit
24:
1839:from the original on 24 March 2024
1788:. Docs.python.org. 5 December 2015
1108:Kevin G. Cassidy (December 1985).
518:
25:
2385:
1895:, Yossi Levanoni and Erez Petrank
1880:
1715:. 27 October 2016. Archived from
700:and removed from the Objective-C
502:and Watson & Watson in 1987.
250:, while another involves using a
2343:
2342:
2333:
2332:
2323:
2322:
2313:
2312:
2303:
2302:
830:Like other low-level languages,
461:
421:often do this. Judicious use of
211:functional programming languages
36:
2165:Concurrent mark sweep collector
1851:
1825:
1800:
1778:
1753:
1731:
1701:
1681:Siracusa, John (25 July 2012).
1674:
1652:
1635:
1600:
1575:
1550:
1485:
1438:
1067:
1037:do not use reference counting.
423:"weak" (non-counted) references
47:needs additional citations for
2290:Region-based memory management
1416:
1372:
1344:
1308:ACM Trans. Program. Lang. Syst
1200:
1152:
1122:
1101:
173:is that objects are reclaimed
13:
1:
1094:
1083:, which are usually known as
413:Dealing with reference cycles
326:Another technique devised by
2338:Memory management algorithms
2150:Automatic Reference Counting
1988:Translation lookaside buffer
1002:Interior mutability without
678:Automatic Reference Counting
648:Automatic Reference Counting
311:performance and can lead to
165:Advantages and disadvantages
7:
2369:Automatic memory management
2328:Automatic memory management
2127:C dynamic memory allocation
1009:
604:provides reference counted
513:Dijkstra–Scholten algorithm
506:Indirect reference counting
471:Weighted reference counting
406:ulterior reference counting
10:
2390:
2348:Memory management software
2195:Tracing garbage collection
2028:Virtual memory compression
762:
645:
171:tracing garbage collection
2298:
2272:
2246:
2213:
2140:
2112:
2069:
2036:
2003:
1974:
1961:
987:often comes bundled with
814:
785:Vala programming language
715:
676:messages to objects, but
626:
620:
610:
447:tracing garbage collector
404:Blackburn and McKinley's
184:Weighted reference counts
2122:Static memory allocation
2114:Manual memory management
1462:10.1007/3-540-45337-7_12
1394:2003. pp. 344–358.
1276:2001. pp. 367–380.
1129:Wilson, Paul R. (1992).
1021:
862:
343:update coalescing method
2180:Garbage-first collector
2155:Boehm garbage collector
2061:x86 memory segmentation
1709:"Xcode 8 Release Notes"
1660:"Mac Developer Library"
1522:10.1145/1255450.1255453
1424:"Mac Developer Library"
1330:10.1145/1111596.1111597
1180:10.1145/2509136.2509527
1081:Unix-style file systems
1055:
825:
790:
453:occurs on are put on a
2185:Mark–compact algorithm
1982:Memory management unit
1040:
852:For example, the type
802:
635:C++11's move semantics
587:
554:Component Object Model
548:Component Object Model
198:
1662:. Developer.apple.com
1609:ACM Computing Surveys
1426:. Developer.apple.com
1400:10.1145/949305.949336
1282:10.1145/504282.504309
1236:10.1145/185009.185016
341:. They introduce the
192:
2132:new and delete (C++)
1833:"The Rust Reference"
1741:. GNOME. 25 May 2015
570:MS Internet Explorer
349:, then to an object
270:Graph interpretation
71:"Reference counting"
56:improve this article
2038:Memory segmentation
1646:9 June 2011 at the
1213:ACM SIGPLAN Notices
642:Cocoa (Objective-C)
332:deferred increments
2280:Automatic variable
2264:Unreachable memory
2190:Reference counting
2160:Cheney's algorithm
2142:Garbage collection
1911:, Guido van Rossum
524:Garbage collection
199:
159:garbage collection
140:reference counting
2374:Memory management
2356:
2355:
2308:Memory management
2056:Virtual 8086 mode
1955:Memory management
1812:doc.rust-lang.org
1471:978-3-540-42206-8
1359:Cs.technion.ac.il
935:"black"
777:atomic operations
398:atomic operations
259:atomic operations
230:context switching
207:immutable objects
132:
131:
124:
106:
16:(Redirected from
2381:
2346:
2345:
2336:
2335:
2326:
2325:
2316:
2315:
2306:
2305:
2233:Dangling pointer
2228:Buffer over-read
2200:Strong reference
2071:Memory allocator
1948:
1941:
1934:
1925:
1924:
1903:, Kirk Reinholtz
1874:
1873:
1871:
1869:
1855:
1849:
1848:
1846:
1844:
1829:
1823:
1822:
1820:
1818:
1808:"std::rc - Rust"
1804:
1798:
1797:
1795:
1793:
1782:
1776:
1775:
1773:
1771:
1757:
1751:
1750:
1748:
1746:
1735:
1729:
1728:
1726:
1724:
1719:on 19 March 2017
1705:
1699:
1698:
1696:
1694:
1678:
1672:
1671:
1669:
1667:
1656:
1650:
1639:
1633:
1632:
1604:
1598:
1597:
1579:
1573:
1572:
1554:
1548:
1547:
1541:
1533:
1515:
1489:
1483:
1482:
1481:on 23 July 2004.
1480:
1474:. Archived from
1451:
1442:
1436:
1435:
1433:
1431:
1420:
1414:
1413:
1385:
1376:
1370:
1369:
1367:
1365:
1356:
1348:
1342:
1341:
1323:
1298:Yossi Levanoni,
1295:
1286:
1285:
1260:Yossi Levanoni,
1257:
1248:
1247:
1229:
1204:
1198:
1197:
1191:
1183:
1165:
1156:
1150:
1148:
1126:
1120:
1118:
1116:
1105:
1032:
1005:
998:
994:
990:
986:
976:
973:
970:
967:
964:
960:
957:
954:
951:
948:
945:
942:
939:
936:
932:
929:
926:
923:
920:
917:
914:
911:
908:
905:
902:
899:
896:
892:
889:
886:
883:
880:
877:
873:
869:
866:
859:
855:
848:
844:
675:
671:
628:
622:
612:
388:
384:
380:
376:
372:
368:
364:
360:
356:
352:
348:
313:pipeline bubbles
242:
241:
240:reference cycles
220:
136:computer science
127:
120:
116:
113:
107:
105:
64:
40:
32:
21:
2389:
2388:
2384:
2383:
2382:
2380:
2379:
2378:
2359:
2358:
2357:
2352:
2294:
2268:
2242:
2223:Buffer overflow
2209:
2136:
2108:
2065:
2032:
1999:
1970:
1957:
1952:
1883:
1878:
1877:
1867:
1865:
1859:"Documentation"
1857:
1856:
1852:
1842:
1840:
1831:
1830:
1826:
1816:
1814:
1806:
1805:
1801:
1791:
1789:
1784:
1783:
1779:
1769:
1767:
1759:
1758:
1754:
1744:
1742:
1737:
1736:
1732:
1722:
1720:
1713:Apple Developer
1707:
1706:
1702:
1692:
1690:
1679:
1675:
1665:
1663:
1658:
1657:
1653:
1648:Wayback Machine
1640:
1636:
1621:10.1145/3156818
1605:
1601:
1594:
1580:
1576:
1569:
1555:
1551:
1535:
1534:
1490:
1486:
1478:
1472:
1449:
1443:
1439:
1429:
1427:
1422:
1421:
1417:
1410:
1383:
1377:
1373:
1363:
1361:
1354:
1350:
1349:
1345:
1296:
1289:
1258:
1251:
1205:
1201:
1188:cite conference
1185:
1184:
1163:
1157:
1153:
1145:
1127:
1123:
1114:
1106:
1102:
1097:
1070:
1058:
1043:
1030:
1024:
1012:
1003:
996:
992:
988:
984:
978:
977:
974:
971:
968:
965:
962:
958:
955:
952:
949:
946:
943:
940:
937:
934:
930:
927:
924:
921:
918:
915:
912:
909:
906:
903:
900:
897:
894:
890:
887:
884:
881:
878:
875:
871:
867:
864:
857:
853:
846:
842:
828:
817:
805:
793:
773:weak references
765:
718:
702:runtime library
673:
669:
662:Core Foundation
650:
644:
627:std::unique_ptr
611:std::shared_ptr
590:
550:
526:
521:
519:Examples of use
508:
473:
464:
415:
386:
382:
378:
374:
370:
366:
362:
358:
354:
350:
346:
305:
276:reference graph
272:
248:weak references
239:
238:
219:str ← str + "a"
218:
167:
128:
117:
111:
108:
65:
63:
53:
41:
28:
23:
22:
18:Reference count
15:
12:
11:
5:
2387:
2377:
2376:
2371:
2354:
2353:
2351:
2350:
2340:
2330:
2320:
2318:Virtual memory
2310:
2299:
2296:
2295:
2293:
2292:
2287:
2282:
2276:
2274:
2270:
2269:
2267:
2266:
2261:
2256:
2250:
2248:
2244:
2243:
2241:
2240:
2238:Stack overflow
2235:
2230:
2225:
2219:
2217:
2211:
2210:
2208:
2207:
2205:Weak reference
2202:
2197:
2192:
2187:
2182:
2177:
2172:
2167:
2162:
2157:
2152:
2146:
2144:
2138:
2137:
2135:
2134:
2129:
2124:
2118:
2116:
2110:
2109:
2107:
2106:
2101:
2096:
2091:
2086:
2081:
2075:
2073:
2067:
2066:
2064:
2063:
2058:
2053:
2048:
2046:Protected mode
2042:
2040:
2034:
2033:
2031:
2030:
2025:
2020:
2015:
2009:
2007:
2005:Virtual memory
2001:
2000:
1998:
1997:
1991:
1985:
1978:
1976:
1972:
1971:
1969:
1968:
1962:
1959:
1958:
1951:
1950:
1943:
1936:
1928:
1922:
1921:
1913:
1905:
1897:
1889:
1882:
1881:External links
1879:
1876:
1875:
1863:docs.swift.org
1850:
1824:
1799:
1777:
1752:
1730:
1700:
1673:
1651:
1634:
1599:
1592:
1574:
1567:
1549:
1513:10.1.1.10.2777
1484:
1470:
1437:
1415:
1408:
1371:
1343:
1321:10.1.1.15.9106
1287:
1249:
1199:
1151:
1143:
1121:
1099:
1098:
1096:
1093:
1069:
1066:
1057:
1054:
1042:
1039:
1023:
1020:
1011:
1008:
863:
827:
824:
816:
813:
804:
801:
792:
789:
764:
761:
760:
759:
755:
751:
747:
743:
739:
736:
726:dynamic arrays
717:
714:
643:
640:
606:smart pointers
589:
586:
549:
546:
525:
522:
520:
517:
507:
504:
472:
469:
463:
460:
414:
411:
304:
301:
280:directed graph
271:
268:
263:
262:
255:
234:
215:runtime system
166:
163:
130:
129:
44:
42:
35:
26:
9:
6:
4:
3:
2:
2386:
2375:
2372:
2370:
2367:
2366:
2364:
2349:
2341:
2339:
2331:
2329:
2321:
2319:
2311:
2309:
2301:
2300:
2297:
2291:
2288:
2286:
2283:
2281:
2278:
2277:
2275:
2271:
2265:
2262:
2260:
2257:
2255:
2254:Fragmentation
2252:
2251:
2249:
2245:
2239:
2236:
2234:
2231:
2229:
2226:
2224:
2221:
2220:
2218:
2216:
2215:Memory safety
2212:
2206:
2203:
2201:
2198:
2196:
2193:
2191:
2188:
2186:
2183:
2181:
2178:
2176:
2173:
2171:
2168:
2166:
2163:
2161:
2158:
2156:
2153:
2151:
2148:
2147:
2145:
2143:
2139:
2133:
2130:
2128:
2125:
2123:
2120:
2119:
2117:
2115:
2111:
2105:
2102:
2100:
2097:
2095:
2092:
2090:
2087:
2085:
2082:
2080:
2077:
2076:
2074:
2072:
2068:
2062:
2059:
2057:
2054:
2052:
2049:
2047:
2044:
2043:
2041:
2039:
2035:
2029:
2026:
2024:
2021:
2019:
2018:Memory paging
2016:
2014:
2013:Demand paging
2011:
2010:
2008:
2006:
2002:
1995:
1992:
1989:
1986:
1983:
1980:
1979:
1977:
1973:
1967:
1964:
1963:
1960:
1956:
1949:
1944:
1942:
1937:
1935:
1930:
1929:
1926:
1920:
1918:
1914:
1912:
1910:
1906:
1904:
1902:
1898:
1896:
1894:
1890:
1888:
1885:
1884:
1864:
1860:
1854:
1838:
1834:
1828:
1813:
1809:
1803:
1787:
1781:
1766:
1762:
1756:
1740:
1734:
1718:
1714:
1710:
1704:
1688:
1684:
1677:
1661:
1655:
1649:
1645:
1642:
1638:
1630:
1626:
1622:
1618:
1614:
1610:
1603:
1595:
1593:0-387-17945-3
1589:
1585:
1578:
1570:
1568:0-387-17945-3
1564:
1560:
1553:
1545:
1539:
1531:
1527:
1523:
1519:
1514:
1509:
1505:
1501:
1500:
1495:
1488:
1477:
1473:
1467:
1463:
1459:
1455:
1448:
1441:
1425:
1419:
1411:
1409:1-58113-712-5
1405:
1401:
1397:
1393:
1389:
1382:
1375:
1360:
1353:
1347:
1339:
1335:
1331:
1327:
1322:
1317:
1313:
1309:
1305:
1301:
1294:
1292:
1283:
1279:
1275:
1271:
1267:
1263:
1256:
1254:
1245:
1241:
1237:
1233:
1228:
1227:10.1.1.25.955
1223:
1219:
1215:
1214:
1209:
1203:
1195:
1189:
1181:
1177:
1173:
1169:
1162:
1155:
1146:
1144:3-540-55940-X
1140:
1136:
1132:
1125:
1113:
1112:
1104:
1100:
1092:
1090:
1086:
1082:
1078:
1075:
1065:
1062:
1053:
1051:
1047:
1038:
1036:
1028:
1019:
1016:
1007:
1000:
981:
861:
850:
839:
837:
833:
823:
821:
812:
809:
800:
797:
788:
786:
781:
778:
774:
770:
756:
752:
748:
744:
740:
737:
734:
733:
732:
729:
727:
722:
713:
711:
707:
703:
699:
695:
694:Mac OS X 10.5
691:
690:Mac OS X 10.7
687:
683:
679:
667:
663:
659:
655:
649:
639:
636:
633:In addition,
631:
629:
623:
621:std::weak_ptr
617:
616:weak pointers
613:
607:
603:
598:
596:
585:
583:
577:
575:
571:
567:
566:Windows Shell
563:
559:
555:
545:
541:
537:
533:
531:
516:
514:
503:
501:
496:
492:
488:
486:
480:
478:
468:
462:Variant forms
459:
456:
450:
448:
444:
439:
436:
430:
428:
424:
420:
410:
407:
402:
399:
394:
390:
344:
340:
335:
333:
329:
324:
320:
316:
314:
310:
300:
296:
293:
288:
287:other nodes.
285:
281:
278:, which is a
277:
267:
260:
256:
253:
249:
244:
235:
231:
227:
226:
225:
222:
216:
212:
209:such as many
208:
203:
196:
191:
187:
185:
181:
176:
172:
162:
160:
155:
153:
149:
145:
141:
137:
126:
123:
115:
104:
101:
97:
94:
90:
87:
83:
80:
76:
73: –
72:
68:
67:Find sources:
61:
57:
51:
50:
45:This article
43:
39:
34:
33:
30:
19:
2189:
1916:
1908:
1900:
1892:
1866:. Retrieved
1862:
1853:
1841:. Retrieved
1827:
1815:. Retrieved
1811:
1802:
1790:. Retrieved
1780:
1768:. Retrieved
1764:
1755:
1743:. Retrieved
1733:
1721:. Retrieved
1717:the original
1712:
1703:
1691:. Retrieved
1687:Ars Technica
1686:
1676:
1664:. Retrieved
1654:
1637:
1612:
1608:
1602:
1583:
1577:
1558:
1552:
1538:cite journal
1506:(4): 20–es.
1503:
1497:
1494:Erez Petrank
1487:
1476:the original
1453:
1440:
1428:. Retrieved
1418:
1387:
1374:
1362:. Retrieved
1358:
1346:
1311:
1307:
1300:Erez Petrank
1269:
1262:Erez Petrank
1220:(9): 38–43.
1217:
1211:
1202:
1167:
1154:
1149:Section 2.1.
1134:
1124:
1110:
1103:
1076:
1071:
1068:File systems
1059:
1044:
1025:
1013:
1001:
982:
979:
851:
840:
829:
818:
806:
794:
782:
766:
730:
719:
706:macOS Sierra
651:
632:
599:
591:
582:Visual Basic
578:
552:Microsoft's
551:
542:
538:
534:
527:
509:
497:
493:
489:
484:
481:
476:
474:
465:
454:
451:
440:
431:
416:
405:
403:
395:
391:
342:
336:
331:
325:
321:
317:
306:
297:
289:
275:
273:
264:
237:
223:
204:
200:
174:
168:
156:
139:
133:
118:
112:October 2015
109:
99:
92:
85:
78:
66:
54:Please help
49:verification
46:
29:
2259:Memory leak
1792:17 December
1765:www.php.net
1745:17 December
1693:17 November
1666:17 December
1430:17 December
1208:Henry Baker
1089:directories
1035:value types
854:Rc<T>
658:Cocoa Touch
485:indirection
328:Henry Baker
2363:Categories
2023:Page table
1868:6 December
1817:2 November
1119:Here: p.25
1095:References
1085:hard links
1077:link count
1004:UnsafeCell
754:assembler.
742:collector.
646:See also:
608:, via the
556:(COM) and
530:references
419:hard links
282:where the
252:mark-sweep
195:cons pairs
180:finalizers
175:as soon as
144:references
82:newspapers
2170:Finalizer
2051:Real mode
1770:1 October
1508:CiteSeerX
1316:CiteSeerX
1314:: 31–69.
1222:CiteSeerX
941:to_string
698:OS X 10.8
574:MS Office
330:involves
319:avoided.
292:in-degree
2104:ptmalloc
2099:mimalloc
2089:jemalloc
2079:dlmalloc
1975:Hardware
1843:22 April
1837:Archived
1723:19 March
1644:Archived
1629:21388487
1615:: 1–35.
1338:14777709
1302:(2006).
1264:(2001).
1244:14448488
1015:Squirrel
1010:Squirrel
758:options.
652:Apple's
595:iterator
562:IUnknown
387:rc(On)++
383:rc(O1)--
379:rc(On)++
375:rc(O3)--
371:rc(O3)++
367:rc(O2)--
363:rc(O2)++
359:rc(O1)--
284:vertices
148:pointers
2175:Garbage
2094:libumem
1996:(IOMMU)
1530:4550008
1364:24 June
1050:structs
836:dropped
769:GObject
763:GObject
674:release
377:, ...,
339:Petrank
152:handles
96:scholar
2247:Issues
1627:
1590:
1565:
1528:
1510:
1468:
1406:
1392:OOPSLA
1336:
1318:
1274:OOPSLA
1242:
1224:
1174:2013.
1172:OOPSLA
1141:
991:, and
895:String
882:struct
820:Python
815:Python
721:Delphi
716:Delphi
688:5 and
670:retain
477:weight
443:detect
98:
91:
84:
77:
69:
2273:Other
2084:Hoard
1990:(TLB)
1984:(MMU)
1625:S2CID
1526:S2CID
1479:(PDF)
1450:(PDF)
1384:(PDF)
1355:(PDF)
1334:S2CID
1240:S2CID
1164:(PDF)
1115:(PDF)
1074:inode
1027:Swift
1022:Swift
997:Mutex
995:with
931:color
891:color
811:run.
682:Clang
654:Cocoa
618:(via
602:C++11
558:WinRT
500:Bevan
455:roots
435:Graph
427:Cocoa
309:cache
150:, or
103:JSTOR
89:books
1870:2023
1845:2024
1819:2020
1794:2015
1772:2020
1747:2015
1725:2017
1695:2016
1668:2015
1588:ISBN
1563:ISBN
1544:link
1466:ISBN
1432:2015
1404:ISBN
1366:2017
1194:link
1139:ISBN
1061:Xojo
1056:Xojo
1031:weak
989:Cell
907:main
845:and
832:Rust
826:Rust
796:Perl
791:Perl
783:The
767:The
680:, a
672:and
656:and
385:and
75:news
1617:doi
1518:doi
1458:doi
1396:doi
1326:doi
1278:doi
1232:doi
1176:doi
1079:on
1046:Tcl
1041:Tcl
993:Arc
969:cat
963:new
953:cat
950:let
925:Cat
919:cat
916:let
885:Cat
868:std
865:use
847:Arc
808:PHP
803:PHP
746:it.
710:iOS
704:in
686:iOS
666:COM
588:C++
157:In
134:In
58:by
2365::
1861:.
1810:.
1763:.
1711:.
1685:.
1623:.
1613:51
1611:.
1540:}}
1536:{{
1524:.
1516:.
1504:29
1502:.
1464:.
1452:.
1402:.
1390:.
1386:.
1357:.
1332:.
1324:.
1312:28
1310:.
1306:.
1290:^
1272:.
1268:.
1252:^
1238:.
1230:.
1218:29
1216:.
1190:}}
1186:{{
1170:.
1166:.
1133:.
985:Rc
972:);
961:::
959:Rc
947:};
944:()
933::
910:()
904:fn
893::
876:Rc
874:::
872:rc
870:::
843:Rc
708:.
692:.
630:.
572:,
373:,
369:,
365:,
361:,
355:On
351:O2
347:O1
146:,
138:,
1947:e
1940:t
1933:v
1872:.
1847:.
1821:.
1796:.
1774:.
1749:.
1727:.
1697:.
1670:.
1631:.
1619::
1596:.
1571:.
1546:)
1532:.
1520::
1460::
1434:.
1412:.
1398::
1368:.
1340:.
1328::
1284:.
1280::
1246:.
1234::
1196:)
1182:.
1178::
1147:.
975:}
966:(
956:=
938:.
928:{
922:=
913:{
901:}
898:,
888:{
879:;
858:T
243:,
125:)
119:(
114:)
110:(
100:·
93:·
86:·
79:·
52:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
