You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 35.171.0.0/16 has been blocked (disabled) by ‪JJMC89‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 05:20, 2 December 2024.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪Jon Kolbert‬. The reason given is Open proxy/Webhost: See the help page if you are affected .
- Start of block: 05:38, 21 February 2024
- Expiry of block: 05:38, 21 February 2029
Your current IP address is 35.171.25.239. The blocked range is 35.171.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((Short description|Form of computer memory management))
((Multiple issues|
((More references|date=July 2016))
((Lead too short|date=March 2024))
))

In [[computer programming]], '''tracing garbage collection''' is a form of [[automatic memory management]] that consists of determining which objects should be deallocated ("garbage collected") by tracing which objects are ''reachable'' by a chain of references from certain "root" objects, and considering the rest as "garbage" and collecting them. Tracing is the most common type of [[garbage collection (computer science)|garbage collection]] – so much so that "garbage collection" often refers to the tracing method, rather than others such as [[reference counting]] – and there are a large number of algorithms used in implementation.

== Reachability of an object ==
Informally, an object is reachable if it is referenced by at least one variable in the program, either directly or through references from other reachable objects. More precisely, objects can be reachable in only two ways:

# A distinguished set of roots: objects that are assumed to be reachable. Typically, these include all the objects referenced from anywhere in the [[call stack]] (that is, all [[local variable]]s and [[Parameter (computer science)|parameters]] in the functions currently being invoked), and any [[global variable]]s.
# Anything referenced from a reachable object is itself reachable; more formally, reachability is a [[transitive closure]].

The reachability definition of "garbage" is not optimal, insofar as the last time a program uses an object could be long before that object falls out of the environment scope. A distinction is sometimes drawn between [[syntactic garbage]], those objects the program cannot possibly reach, and [[semantic garbage]], those objects the program will in fact never again use. For example:
<syntaxhighlight lang="java">
Object x = new Foo();
Object y = new Bar();
x = new Quux();
/* At this point, we know that the Foo object 
 * originally assigned to x will never be
 * accessed: it is syntactic garbage.
 */

/* In the following block, y *could* be semantic garbage;
 * but we won't know until x.check_something() returns
 * some value -- if it returns at all.
 */
if (x.check_something()) {
    x.do_something(y);
}
System.exit(0);
</syntaxhighlight>

The problem of precisely identifying semantic garbage can easily be shown to be [[decision problem|partially decidable]]: a program that allocates an object ''X'', runs an arbitrary input program ''P'', and uses ''X'' if and only if ''P'' finishes would require a semantic garbage collector to solve the [[halting problem]]. Although conservative heuristic methods for semantic garbage detection remain an active research area, essentially all practical garbage collectors focus on syntactic garbage.((Citation needed|date=September 2008))

Another complication with this approach is that, in languages with both [[reference type]]s and unboxed [[value type]]s, the garbage collector needs to somehow be able to distinguish which variables on the stack or fields in an object are regular values and which are references: in memory, an integer and a reference might look alike. The garbage collector then needs to know whether to treat the element as a reference and follow it, or whether it is a primitive value. One common solution is the use of [[tagged pointer]]s.

== Strong and weak references ==
The garbage collector can reclaim only objects that have no references pointing to them either directly or indirectly from the root set. However, some programs require [[weak reference]]s, which should be usable for as long as the object exists but should not prolong its lifetime. In discussions about weak references, ordinary references are sometimes called [[strong reference]]s. An object is eligible for garbage collection if there are no strong (i.e. ordinary) references to it, even though there still might be some weak references to it.

A weak reference is not merely just any pointer to the object that a garbage collector does not care about. The term is usually reserved for a properly managed category of special reference objects which are safe to use even after the object disappears because they ''lapse'' to a safe value (usually <code>null</code>). An unsafe reference that is not known to the garbage collector will simply remain dangling by continuing to refer to the address where the object previously resided. This is not a weak reference.

In some implementations, weak references are divided into subcategories. For example, the [[Java virtual machine|Java Virtual Machine]] provides three forms of weak references, namely [[soft reference]]s,<ref>((cite web |url=http://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html |title=Class SoftReference&lt;T&gt; |publisher=Oracle |website=Java™ Platform Standard Ed.&nbsp;7 |access-date=25 May 2013))</ref> [[phantom reference]]s,<ref>((cite web |url=http://docs.oracle.com/javase/7/docs/api/java/lang/ref/PhantomReference.html |title=Class PhantomReference&lt;T&gt; |publisher=Oracle |website=Java™ Platform Standard Ed.&nbsp;7 |access-date=25 May 2013))</ref> and regular weak references.<ref>((cite web |url=http://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html |title=Class WeakReference&lt;T&gt; |publisher=Oracle |website=Java™ Platform Standard Ed.&nbsp;7 |access-date=25 May 2013))</ref> A softly referenced object is only eligible for reclamation if the garbage collector decides that the program is low on memory. Unlike a soft reference or a regular weak reference, a phantom reference does not provide access to the object that it references. Instead, a phantom reference is a mechanism that allows the garbage collector to notify the program when the referenced object has become ''phantom reachable''. An object is phantom reachable, if it still resides in memory and it is referenced by a phantom reference, but its [[finalizer]] has already executed. Similarly, [[.NET Framework|Microsoft.NET]] provides two subcategories of weak references,<ref>((cite web |url=http://msdn.microsoft.com/en-us/library/ms404247.aspx |title=Weak References |publisher=Microsoft |website=.NET Framework&nbsp;4.5 |access-date=25 May 2013))</ref> namely long weak references (tracks resurrection) and short weak references.

== Weak collections ==
[[Data structure]]s can also be devised which have weak tracking features. For instance, weak [[hash table]]s are useful. Like a regular hash table, a weak hash table maintains an association between pairs of objects, where each pair is understood to be a key and value. However, the hash table does not actually maintain a strong reference on these objects. Special behavior takes place when either the key or value or both become garbage: the hash table entry is spontaneously deleted. There exist further refinements such as hash tables which have only weak keys (value references are ordinary, strong references) or only weak values (key references are strong).

Weak hash tables are important for maintaining associations between objects, such that the objects engaged in the association can still become garbage if nothing in the program refers to them any longer (other than the associating hash table).

The use of a regular hash table for such a purpose could lead to a "logical memory leak": the accumulation of reachable data which the program does not need and will not use.

== Basic algorithm ==
Tracing collectors are so called because they trace through the working set of memory. These garbage collectors perform collection in cycles. It is common for cycles to be triggered when there is not enough free memory for the memory manager to satisfy an allocation request. But cycles can often be requested by the mutator directly or run on a time schedule. The original method involves a naïve ''mark-and-sweep'' in which the entire memory set is touched several times.

=== Naïve mark-and-sweep ===
[[File:Animation of the Naive Mark and Sweep Garbage Collector Algorithm.gif|thumb|upright=1.5|Naive mark-and-sweep in action on a [[Dynamic memory allocation#Manual memory management|heap]] containing eight [[Object (computer science)|objects]].  Arrows represent [[Reference (computer science)#References in object oriented languages|object references]]. Circles represent the objects themselves.  Objects #1, #2, #3, #4, and #6 are strongly referenced from the root set. On the other hand, objects #5, #7, and #8 are not strongly referenced either directly or indirectly from the root set; therefore, they are garbage. ]]

In the naive mark-and-sweep method, each object in memory has a flag (typically a single bit) reserved for garbage collection use only. This flag is always ''cleared'', except during the collection cycle. 

The first stage is the ''mark stage'' which does a tree traversal of the entire 'root set' and marks each object that is pointed to by a root as being 'in-use'. All objects that those objects point to, and so on, are marked as well, so that every object that is reachable via the root set is marked.

In the second stage, the ''sweep stage'', all memory is scanned from start to finish, examining all free or used blocks; those not marked as being 'in-use' are not reachable by any roots, and their memory is freed. For objects which were marked in-use, the in-use flag is cleared, preparing for the next cycle.

This method has several disadvantages, the most notable being that the entire system must be suspended during collection; no mutation of the working set can be allowed. This can cause programs to 'freeze' periodically (and generally unpredictably), making some real-time and time-critical applications impossible. In addition, the entire working memory must be examined, much of it twice, potentially causing problems in [[paged memory]] systems.

=== ((Anchor|TRI-COLOR))Tri-color marking ===
[[File:Animation of tri-color garbage collection.gif|thumb|upright=1.5|
An example of tri-color marking on a heap with 8 objects. 
White, grey, and black objects are represented by light-grey, yellow, and blue, respectively.]]

Because of these performance problems, most modern tracing garbage collectors implement some variant of the ''tri-color marking'' [[abstraction (computer science)|abstraction]], but simple collectors (such as the ''mark-and-sweep'' collector) often do not make this abstraction explicit.  Tri-color marking works as described below.

Three sets are created((snd)) ''white'', ''black'' and ''grey'':

* The white set, or ''condemned set'', is the set of objects that are candidates for having their memory recycled.
* The black set is the set of objects that can be shown to have no outgoing references to objects in the white set, and to be reachable from the roots. Objects in the black set are not candidates for collection.
* The grey set contains all objects reachable from the roots but yet to be scanned for references to "white" objects. Since they are known to be reachable from the roots, they cannot be garbage-collected and will end up in the black set after being scanned. 

In many algorithms, initially the black set starts as empty, the grey set is the set of objects which are directly referenced from roots and the white set includes all other objects. Every object in memory is at all times in exactly one of the three sets. The algorithm proceeds as following:

# Pick an object o from the grey set
# Move each white object o references to the grey set. This ensures that neither this object nor any object it references can be garbage-collected.
# Move o to the black set
# Repeat the last three steps until the grey set is empty.

When the grey set is empty, the scan is complete; the black objects are reachable from the roots, while the white objects are not and can be garbage-collected.

Since all objects not immediately reachable from the roots are added to the white set, and objects can only move from white to grey and from grey to black, the algorithm preserves an important invariant((snd)) no black objects reference white objects. This ensures that the white objects can be freed once the grey set is empty. This is called ''the tri-color invariant''. Some variations on the algorithm do not preserve this invariant but use a modified form for which all the important properties hold.

The tri-color method has an important advantage((snd)) it can be performed "on-the-fly", without halting the system for significant periods of time. This is accomplished by marking objects as they are allocated and during mutation, maintaining the various sets. By monitoring the size of the sets, the system can perform garbage collection periodically, rather than as needed. Also, the need to touch the entire working set on each cycle is avoided.

== Implementation strategies ==

=== Moving vs. non-moving ===
Once the unreachable set has been determined, the garbage collector may simply release the [[unreachable object]]s and leave everything else as it is, or it may copy some or all of the reachable objects into a new area of memory, updating all references to those objects as needed. These are called "non-moving" and "moving" (or, alternatively, "non-compacting" and "compacting") garbage collectors, respectively.

At first, a moving algorithm may seem inefficient compared to a non-moving one, since much more work would appear to be required on each cycle. But the moving algorithm leads to several performance advantages, both during the garbage collection cycle itself and during program execution:
* No additional work is required to reclaim the space freed by dead objects; the entire region of memory from which reachable objects were moved can be considered free space. In contrast, a non-moving GC must visit each unreachable object and record that the memory it occupied is available.
* Similarly, new objects can be allocated very quickly. Since large contiguous regions of memory are usually made available by a moving GC, new objects can be allocated by simply incrementing a 'free memory' pointer. A non-moving strategy may, after some time, lead to a heavily [[fragmentation (computer)|fragmented]] heap, requiring expensive consultation of "free lists" of small available blocks of memory in order to allocate new objects.
* If an appropriate traversal order is used (such as cdr-first for list [[cons]]es), objects can be moved very close to the objects they refer to in memory, increasing the chance that they will be located in the same [[cache line]] or [[virtual memory]] page. This can significantly speed up access to these objects through these references.

One disadvantage of a moving garbage collector is that it only allows access through references that are managed by the garbage collected environment, and does not allow [[pointer arithmetic]]. This is because any pointers to objects will be invalidated if the garbage collector moves those objects (they become [[dangling pointer]]s). For [[interoperability]] with native code, the garbage collector must copy the object contents to a location outside of the garbage collected region of memory. An alternative approach is to ''pin'' the object in memory, preventing the garbage collector from moving it and allowing the memory to be directly shared with native pointers (and possibly allowing pointer arithmetic).<ref>((cite web |url=https://docs.microsoft.com/en-us/dotnet/framework/interop/copying-and-pinning |title=Copying and Pinning |work=[[Microsoft Docs]] |access-date=2022-04-25))</ref>

=== Copying vs. mark-and-sweep vs. mark-and-don't-sweep ===
Not only do collectors differ in whether they are moving or non-moving, they can also be categorized by how they treat the white, grey and black object sets during a collection cycle.

The most straightforward approach is the ''semi-space collector'', which dates to 1969. In this moving collector, memory is partitioned into an equally sized "from space" and "to space". Initially, objects are allocated in "to space" until it becomes full and a collection cycle is triggered. At the start of the cycle, the "to space" becomes the "from space", and vice versa. The objects reachable from the root set are copied from the "from space" to the "to space". These objects are scanned in turn, and all objects that they point to are copied into "to space", until all reachable objects have been copied into "to space". Once the program continues execution, new objects are once again allocated in the "to space" until it is once again full and the process is repeated. 

This approach is very simple, but since only one semi space is used for allocating objects, the memory usage is twice as high compared to other algorithms. The technique is also known as ''stop-and-copy''. [[Cheney's algorithm]] is an improvement on the semi-space collector.

A mark and sweep garbage collector keeps a bit or two with each object to record if it is white or black. The grey set is kept as a separate list or using another bit. As the reference tree is traversed during a collection cycle (the "mark" phase), these bits are manipulated by the collector. A final "sweep" of the memory areas then frees white objects. The mark and sweep strategy has the advantage that, once the condemned set is determined, either a moving or non-moving collection strategy can be pursued. This choice of strategy can be made at runtime, as available memory permits. It has the disadvantage of "bloating" objects by a small amount, as in, every object has a small hidden memory cost because of the list/extra bit. This can be somewhat mitigated if the collector also handles allocation, since then it could potentially use unused bits in the allocation data structures. Or, this "hidden memory" can be eliminated by using a [[Tagged pointer]], trading the memory cost for CPU time. However, the mark and sweep is the only strategy that readily cooperates with external allocators in the first place.

A ''mark and don't sweep'' garbage collector, like the mark-and-sweep, keeps a bit with each object to record if it is white or black; the grey set is kept as a separate list or using another bit. There are two key differences here. First, black and white mean different things than they do in the mark and sweep collector. In a "mark and don't sweep" collector, all reachable objects are always black. An object is marked black at the time it is allocated, and it will stay black even if it becomes unreachable. A white object is unused memory and may be allocated. Second, the interpretation of the black/white bit can change. Initially, the black/white bit may have the sense of (0=white, 1=black). If an allocation operation ever fails to find any available (white) memory, that means all objects are marked used (black). The sense of the black/white bit is then inverted (for example, 0=black, 1=white). Everything becomes white. This momentarily breaks the invariant that reachable objects are black, but a full marking phase follows immediately, to mark them black again. Once this is done, all unreachable memory is white. No "sweep" phase is necessary. 

The mark and don't sweep strategy requires cooperation between the allocator and collector, but is incredibly space efficient since it only requires one bit per allocated pointer (which most allocation algorithms require anyway). However, this upside is somewhat mitigated, since most of the time large portions of memory are wrongfully marked black (used), making it hard to give resources back to the system (for use by other allocators, threads, or processes) in times of low memory usage. 

The mark and don't sweep strategy can therefore be seen as a compromise between the upsides and downsides of the mark and sweep and the stop and copy strategies.

=== Generational GC (ephemeral GC) ===
It has been empirically observed that in many programs, the most recently created objects are also those most likely to become unreachable quickly (known as ''infant mortality'' or the ''generational hypothesis''). <!--
the following sentence is embarrassing without a reference, someone please find one

Experimental evidence shows that around 90% of objects die before their first garbage collection. --> A generational GC (also known as ephemeral GC) divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial white (condemned) set. Furthermore, the runtime system maintains knowledge of when references cross generations by observing the creation and overwriting of references. When the garbage collector runs, it may be able to use this knowledge to prove that some objects in the initial white set are unreachable without having to traverse the entire reference tree. If the generational hypothesis holds, this results in much faster collection cycles while still reclaiming most unreachable objects.

In order to implement this concept, many generational garbage collectors use separate memory regions for different ages of objects. When a region becomes full, the objects in it are traced, using the references from the older generation(s) as roots.  This usually results in most objects in the generation being collected (by the hypothesis), leaving it to be used to allocate new objects.  When a collection doesn't collect many objects (the hypothesis doesn't hold, for example because the program has computed a large collection of new objects it does want to retain), some or all of the surviving objects that are referenced from older memory regions are promoted to the next highest region, and the entire region can then be overwritten with fresh objects. This technique permits very fast incremental garbage collection, since the garbage collection of only one region at a time is all that is typically required.

[[David Ungar|Ungar]]'s classic generation scavenger has two generations. It divides the youngest generation, called "new space", into a large "eden" in which new objects are created and two smaller "survivor spaces", past survivor space and future survivor space. The objects in the older generation that may reference objects in new space are kept in a "remembered set". On each scavenge, the objects in new space are traced from the roots in the remembered set and copied to future survivor space. If future survivor space fills up, the objects that do not fit are promoted to old space, a process called "tenuring". At the end of the scavenge, some objects reside in future survivor space, and eden and past survivor space are empty. Then future survivor space and past survivor space are exchanged and the program continues, allocating objects in eden. In Ungar's original system, eden is 5 times larger than each survivor space.

Generational garbage collection is a [[heuristic (computer science)|heuristic]] approach, and some unreachable objects may not be reclaimed on each cycle. It may therefore occasionally be necessary to perform a full mark and sweep or copying garbage collection to reclaim all available space. In fact, runtime systems for modern programming languages (such as [[Java (programming language)|Java]] and the [[.NET Framework]]) usually use some hybrid of the various strategies that have been described thus far; for example, most collection cycles might look only at a few generations, while occasionally a mark-and-sweep is performed, and even more rarely a full copying is performed to combat fragmentation. The terms "minor cycle" and "major cycle" are sometimes used to describe these different levels of collector aggression.

=== Stop-the-world vs. incremental vs. concurrent ===

Simple ''stop-the-world'' garbage collectors completely halt execution of the program to run a collection cycle, thus guaranteeing that new objects are not allocated and objects do not suddenly become unreachable while the collector is running.

This has the disadvantage that the program can perform no useful work while a collection cycle is running (sometimes called the "embarrassing pause"<ref>((cite journal |last1=Steele |first1=Guy L. |author-link=Guy L. Steele Jr. |title=Multiprocessing Compactifying Garbage Collection |journal=Communications of the ACM |date=September 1975 |volume=18 |issue=9 |pages=495–508 |doi=10.1145/361002.361005 |doi-access=free |s2cid=29412244))</ref>). Stop-the-world garbage collection is therefore mainly suitable for non-interactive programs. Its advantage is that it is both simpler to implement and faster than incremental garbage collection.

''Incremental'' and ''concurrent'' garbage collectors are designed to reduce this disruption by interleaving their work with activity from the main program. ''Incremental'' garbage collectors perform the garbage collection cycle in discrete phases, with program execution permitted between each phase (and sometimes during some phases). ''Concurrent'' garbage collectors do not stop program execution at all, except perhaps briefly when the program's execution stack is scanned. However, the sum of the incremental phases takes longer to complete than one batch garbage collection pass, so these garbage collectors may yield lower total throughput.

Careful design is necessary with these techniques to ensure that the main program does not interfere with the garbage collector and vice versa; for example, when the program needs to allocate a new object, the runtime system may either need to suspend it until the collection cycle is complete, or somehow notify the garbage collector that there exists a new, reachable object.

=== Precise vs. conservative and internal pointers ===
Some collectors can correctly identify all pointers (references) in an object; these are called ''precise'' (also ''exact'' or ''accurate'') collectors, the opposite being a ''conservative'' or ''partly conservative'' collector. Conservative collectors assume that any bit pattern in memory could be a pointer if, interpreted as a pointer, it would point into an allocated object. Conservative collectors may produce false positives, where unused memory is not released because of improper pointer identification. This is not always a problem in practice unless the program handles a lot of data that could easily be misidentified as a pointer. False positives are generally less problematic on [[64-bit computing|64-bit]] systems than on [[32-bit]] systems because the range of valid memory addresses tends to be a tiny fraction of the range of 64-bit values. Thus, an arbitrary 64-bit pattern is unlikely to mimic a valid pointer. A false negative can also happen if pointers are "hidden", for example using an [[XOR linked list]]. Whether a precise collector is practical usually depends on the type safety properties of the programming language in question. An example for which a conservative garbage collector would be needed is the [[C (programming language)|C language]], which allows typed (non-void) pointers to be type cast into untyped (void) pointers, and vice versa.

A related issue concerns ''internal pointers'', or pointers to fields within an object. If the semantics of a language allow internal pointers, then there may be many different addresses that can refer to parts of the same object, which complicates determining whether an object is garbage or not. An example for this is the [[C++]] language, in which multiple inheritance can cause pointers to base objects to have different addresses. In a tightly optimized program, the corresponding pointer to the object itself may have been overwritten in its register, so such internal pointers need to be scanned.

== Performance ==
Performance of tracing garbage collectors – both latency and throughput – depends significantly on the implementation, workload, and environment. Naive implementations or use in very memory-constrained environments, notably embedded systems, can result in very poor performance compared with other methods, while sophisticated implementations and use in environments with ample memory can result in excellent performance. ((Citation needed|date=February 2020))

In terms of throughput, tracing by its nature requires some implicit runtime [[computational overhead|overhead]], though in some cases the amortized cost can be extremely low, in some cases even lower than one instruction per allocation or collection, outperforming stack allocation.<ref>((cite journal |last=Appel |first=Andrew W. |author-link=Andrew Appel |date=1987-06-17 |df=mdy |title=Garbage collection can be faster than stack allocation |journal=Information Processing Letters |volume=25 |issue=4 |pages=275–279 |citeseerx=10.1.1.49.2537 |doi=10.1016/0020-0190(87)90175-X |s2cid=2575400 |url=https://www.cs.princeton.edu/~appel/papers/45.pdf |access-date=2022-04-25))</ref> Manual memory management requires overhead due to explicit freeing of memory, and reference counting has overhead from incrementing and decrementing reference counts, and checking if the count has overflowed or dropped to zero. ((Citation needed|date=February 2020))

In terms of latency, simple stop-the-world garbage collectors pause program execution for garbage collection, which can happen at arbitrary times and take arbitrarily long, making them unusable for [[real-time computing]], notably embedded systems, and a poor fit for interactive use, or any other situation where low latency is a priority. However, incremental garbage collectors can provide hard real-time guarantees, and on systems with frequent idle time and sufficient free memory, such as personal computers, garbage collection can be scheduled for idle times and have minimal impact on interactive performance. Manual memory management (as in C++) and reference counting have a similar issue of arbitrarily long pauses in case of deallocating a large data structure and all its children, though these only occur at fixed times, not depending on garbage collection. ((Citation needed|date=February 2020))

; Manual heap allocation:
* search for best/first-fit block of sufficient size
* free list maintenance

; Garbage collection:
* locate reachable objects
* copy reachable objects for moving collectors
* read/write barriers for incremental collectors
* search for best/first-fit block and free list maintenance for non-moving collectors

It is difficult to compare the two cases directly, as their behavior depends on the situation. For example, in the best case for a garbage collecting system, allocation just increments a pointer, but in the best case for manual heap allocation, the allocator maintains freelists of specific sizes and allocation only requires following a pointer. However, this size segregation usually cause a large degree of external fragmentation, which can have an adverse impact on cache behaviour. Memory allocation in a garbage collected language may be implemented using heap allocation behind the scenes (rather than simply incrementing a pointer), so the performance advantages listed above don't necessarily apply in this case. In some situations, most notably [[embedded system]]s, it is possible to avoid both garbage collection and heap management overhead by preallocating pools of memory and using a custom, lightweight scheme for allocation/deallocation.<ref>((cite mailing list |last=Hopwood |first=David |date=2007-01-01 |df=mdy |title=Memory allocation in embedded systems |mailing-list=cap-talk |publisher=[[EROS (microkernel)|EROS]] |url=http://www.eros-os.org/pipermail/cap-talk/2007-January/006795.html |archive-url=https://web.archive.org/web/20150924001857/http://www.eros-os.org/pipermail/cap-talk/2007-January/006795.html |archive-date=2015-09-24))</ref>

The overhead of write barriers is more likely to be noticeable in an [[imperative programming|imperative]]-style program which frequently writes pointers into existing data structures than in a [[functional programming|functional]]-style program which constructs data only once and never changes them.

Some advances in garbage collection can be understood as reactions to performance issues. Early collectors were stop-the-world collectors, but the performance of this approach was distracting in interactive applications. Incremental collection avoided this disruption, but at the cost of decreased efficiency due to the need for barriers. Generational collection techniques are used with both stop-the-world and incremental collectors to increase performance; the trade-off is that some garbage is not detected as such for longer than normal.

== Determinism ==
* Tracing garbage collection is not [[deterministic algorithm|deterministic]] in the timing of object finalization. An object which becomes eligible for garbage collection will usually be cleaned up eventually, but there is no guarantee when (or even if) that will happen. This is an issue for program correctness when objects are tied to non-memory resources, whose release is an externally visible program behavior, such as closing a network connection, releasing a device or closing a file. One garbage collection technique which provides determinism in this regard is [[reference counting]].
* Garbage collection can have a nondeterministic impact on execution time, by potentially introducing pauses into the execution of a program which are not correlated with the algorithm being processed. Under tracing garbage collection, the request to allocate a new object can sometimes return quickly and at other times trigger a lengthy garbage collection cycle. Under reference counting, whereas allocation of objects is usually fast, decrementing a reference is nondeterministic, since a reference may reach zero, triggering recursion to decrement the reference counts of other objects which that object holds.

== Real-time garbage collection ==

While garbage collection is generally nondeterministic, it is possible to use it in hard [[real-time computing|real-time]] systems. A real-time garbage collector should guarantee that even in the worst case it will dedicate a certain number of computational resources to mutator threads. Constraints imposed on a real-time garbage collector are usually either work based or time based. A time based constraint would look like: within each time window of duration ''T'', mutator threads should be allowed to run at least for ''Tm'' time. For work based analysis, MMU (minimal mutator utilization)<ref>((cite journal |first1=Perry |last1=Cheng |first2=Guy E. |last2=Blelloch |date=2001-06-22  |df=mdy |title=A Parallel, Real-Time Garbage Collector |journal=ACM SIGPLAN Notices |volume=36 |issue=5 |pages=125–136 |doi=10.1145/381694.378823 |url=http://www.aladdin.cs.cmu.edu/papers/pdfs/y2001/rtg.pdf))</ref> is usually used as a real-time constraint for the garbage collection algorithm.

One of the first implementations of [[hard real-time]] garbage collection for the [[JVM]] was based on the [[Metronome algorithm]],<ref>((cite conference |last1=Bacon |first1=David F. |last2=Cheng |first2=Perry |last3=Rajan |first3=V. T. |date=November 2003 |title=The Metronome: A Simpler Approach to Garbage Collection in Real-Time Systems |editor-last1=Corsaro |editor-first1=Angelo |editor-last2=Cytron |editor-first2=Ron |editor-last3=Santoro |editor-first3=Corrado |book-title=Workshop on Java Technologies for Real-Time and Embedded Systems |department=JTRES'03 |conference=OTM 2003 Workshops |work=On The Move to Meaningful Internet Systems 2003 |series=[[Lecture Notes in Computer Science|LNCS]] |volume=2889 |pages=466–478 |citeseerx=10.1.1.3.8544 |doi=10.1007/978-3-540-39962-9_52 |isbn=3-540-20494-6 |issn=0302-9743 |s2cid=14565934 |url=http://www.research.ibm.com/people/d/dfb/papers/Bacon03Metronome.pdf |archive-url=https://web.archive.org/web/20061026215158/http://www.research.ibm.com/people/d/dfb/papers/Bacon03Metronome.pdf |archive-date=2006-10-26))</ref> whose commercial implementation is available as part of the [[IBM WebSphere Real Time]].<ref>((cite web |last1=Biron |first1=Benjamin |last2=Sciampacone |first2=Ryan |date=2007-05-02 |df=mdy |title=Real-time Java, Part 4: Real-time garbage collection |work=[[IBM DeveloperWorks]] |url=http://www.ibm.com/developerworks/java/library/j-rtj4/index.html |archive-url=https://web.archive.org/web/20201109040826/http://www.ibm.com/developerworks/java/library/j-rtj4/index.html |archive-date=2020-11-09))</ref> Another hard real-time garbage collection algorithm is Staccato, available in the [[IBM]]'s [[IBM J9|J9 JVM]], which also provides scalability to large multiprocessor architectures, while bringing various advantages over Metronome and other algorithms which, on the contrary, require specialized hardware.<ref>((cite tech report |last1=McCloskey |first1=Bill |last2=Bacon |first2=David F. |last3=Cheng |first3=Perry |last4=Grove |first4=David |date=2008-02-22 |df=mdy |title=Staccato: A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors |institution=IBM Research Division |number=RC24504 |url=https://dominoweb.draco.res.ibm.com/reports/rc24504.pdf |access-date=2022-04-25))</ref>

One major challenge for real-time garbage collection on modern multi-core architectures is in designing a non-blocking concurrent garbage collection, not letting the concurrent threads block each other and create unpredictable pauses. A study of algorithms that allow non-blocking real-time concurrent garbage collection appears in a paper by Pizlo et al. in Microsoft Research.<ref>((cite conference |last1=Pizlo |first1=Phil |author2-link=Erez Petrank |last2=Petrank |first2=Erez |last3=Steensgaard |first3=Bjarne |date=June 2008 |title=Proceedings of the 29th ACM SIGPLAN Conference on Programming Language Design and Implementation | conference=PLDI 2008 Conferenece |  pages=33–44 |citeseerx=10.1.1.3.8544 |doi=10.1145/1375581.1375587 |isbn= 9781595938602 | url=http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf ))</ref>

==See also==
*[[Dead-code elimination]]
*[[Mark–compact algorithm]]

==References==
((Reflist|30em))

((Memory management))
[[Category:Automatic memory management]]

Pages transcluded onto the current version of this page (help):

Tracing garbage collection (edit)
Template:Ambox (view source) (template editor protected)
Template:Anchor (view source) (template editor protected)
Template:C (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite conference (view source) (protected)
Template:Cite journal (view source) (protected)
Template:Cite mailing list (view source) (protected)
Template:Cite tech report (view source) (semi-protected)
Template:Cite web (view source) (protected)
Template:Delink (view source) (protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:Hlist/styles.css (view source) (protected)
Template:Icon (view source) (template editor protected)
Template:Lead too short (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:Memory management (edit)
Template:More citations needed (view source) (template editor protected)
Template:More references (view source) (extended confirmed protected)
Template:Multiple issues (view source) (template editor protected)
Template:Multiple issues/styles.css (view source) (template editor protected)
Template:Navbox (view source) (template editor protected)
Template:Pagetype (view source) (protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Snd (view source) (template editor protected)
Template:Spaced en dash (view source) (template editor protected)
Module:Anchor (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:Icon (view source) (template editor protected)
Module:Icon/data (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Tracing garbage collection.

Retrieved from "https://en.wikipedia.org/wiki/Tracing_garbage_collection"