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